Modules: I opened a PR to mime-db to improve mime-type recognition in the community

Created on 25 Feb 2020  ·  9Comments  ·  Source: nodejs/modules

Hi y'all, just wanted to let you know that .cjs files are being served with a text/plain mime type by some popular CDNs (such as unpkg.com).

I think the root cause is that the mime-db package on npm needs to be updated, so I opened this PR: https://github.com/jshttp/mime-db/pull/186 Y'all might be interested in reviewing it or giving it a thumbs up. 🤷‍♂

(Before anyone says "but .cjs is a Node thing why should mime type matter!" it's because many CommonJS modules in the wild are _also_ valid AMD or UMD modules and thus are used on the web, and not being able to rename them to .cjs hinders converting to "type": "module" packages.)

Most helpful comment

Also posted on that PR: I don't think .cjs should ever be served with application/javascript since that defies the point of having an extension that clearly means "this is CommonJS". If it could be a JavaScript script and is supposed to be served as application/javascript, it should be using .js or yet-another-extension-somebody-comes-up-with.

All 9 comments

Thanks for letting us know. The thing is, the correct MIME type for .cjs is application/node, which is already one of the types for .js too.

Why does the MIME type of a non-ES module script matter?

cc @mjackson to fix unpkg for .cjs (and .mjs, just in case that's not already fixed).

That said, I don't expect many new CJS modules to use UMD, only ancient ones or the occasional highly-popular framework, and only new ones would use .cjs, so it shouldn't be a huge problem in practice.

Why does the MIME type of a non-ES module script matter?

Module support is still missing from Web Workers in most browsers, and not supported in Service Workers in any browser yet AFAIK. And attempting to use a .cjs script via importScripts in a worker when the server serves it as text/plain results in the script failing. 😢 As I discovered this morning.

Also posted on that PR: I don't think .cjs should ever be served with application/javascript since that defies the point of having an extension that clearly means "this is CommonJS". If it could be a JavaScript script and is supposed to be served as application/javascript, it should be using .js or yet-another-extension-somebody-comes-up-with.

@jkrems Yay! this is exactly why I shared it here. could have been very bad if that PR got merge then, haha. Should I close that PR or modify it to use application/node do you think?

Meanwhile, @mjackson don't worry about .cjs just yet, it sounds like the problem is me not mime 😆.

application/node seems appropriate.

FYI, the “correct” MIME type of ES module JavaScript is text/javascript, not application/javascript, per the WHATWG spec: https://html.spec.whatwg.org/multipage/scripting.html. In practice browsers seem to accept either.

Yay! this is exactly why I shared it here.

Thanks a lot for letting us know! I don't think we had the effect of type: module on projects that use UMD on our radar. We should make sure that we document this gotcha.

The relevant PR has been merged

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Jamesernator picture Jamesernator  ·  4Comments

guybedford picture guybedford  ·  3Comments

MylesBorins picture MylesBorins  ·  3Comments

GeoffreyBooth picture GeoffreyBooth  ·  5Comments

MylesBorins picture MylesBorins  ·  5Comments