Exception for Multer to release v3 with ESM

[bjohansebas]

Hi, I would like to request an exception for the ESM/CommonJS ADR (#323) to release Multer version 2, since one of its dependencies is ESM (https://www.npmjs.com/package/file-type), which makes this module unable to be CommonJS.

The other option is to fork file-type and convert it to CommonJS, but do we really want that? Or look for an alternative to that package, or move the support of v2 to Node >= 22.12 (which would go against the LTS plan).

Ref:

• Plans for v2? multer#1042 (comment)
• It is used, behind (https://www.npmjs.com/package/stream-file-type), which depends on the new version (https://github.com/expressjs/multer/blob/d983eb219979ec41936fd29d9db24e51fad9d0f3/package.json#L30)

cc: @expressjs/express-tc @expressjs/multer-collaborators @UlisesGascon @LinusU

[ljharb]

why not just use a pre-ESM major? That's what most of the ecosystem does with ESM-only packages.

[ctcpip]

must be outdated comments because we don't use that dependency so this is a non-issue

[ctcpip]

also, please note that multer v2 is going to be a security release using the v1 API due to breaking changes. the new API, which was slated for v2, is going to need to go into v3 (or later)

[bjohansebas]

@ctcpip It is used, behind (https://www.npmjs.com/package/stream-file-type), which depends on the new version (https://github.com/expressjs/multer/blob/d983eb219979ec41936fd29d9db24e51fad9d0f3/package.json#L30)

[ctcpip]

ah, ok

[ctcpip]

discussed in the TC today. it's worth noting, if you look at the commits, we could easily revert the change to ESM, if that's how we wanted to proceed. so, in other words, we have options

edit: forgot the root issue is file-type, and there we should check as Jordan suggested, whether we can use the previous major, if stable/secure, etc.

as of right now, our goal would be to find a way to publish a future multer v3 initial release with CJS

[LinusU]

I posted this in November 2021 on why I chose to use the latest file-type version:

I felt like file type detection was a very requested feature, and I didn't want to ship an old version that won't be receiving updates since I know that there will be issues opened with "why isn't file type X supported" 😅

Sorry for missing the TC meetings, I've been very swamped with work lately and haven't had as much time as I'd wish for open source work...

---

Another idea would be to modify the lib to require the user to pass in an instance of file-type. Something like passing a function in that receives the first 4100 byte of the file, and returns Promise<{ ext: string, mime: string } | undefined>.

The drawback is that it's not as easy for beginners to just get started with, which is sort of why I added this feature from the beginning 😅

e.g.

import multer from 'multer'
import { fileTypeFromBuffer } from 'file-type'

const upload = multer({ fileTypeDetector: async (chunk) => await fileTypeFromBuffer(chunk) })

---

Another idea could be to lazy load file-type since it's always used in an asynchronous context. The drawback of this is that it could mess with some bundlers...