This repository was archived by the owner on Sep 2, 2023. It is now read-only.
This repository was archived by the owner on Sep 2, 2023. It is now read-only.
Proposal: extension map in package.json #283
Description
Internally in the fork, we seem to have an extensionFormatMap, which is something exactly like:
{
'__proto__': null,
".js": "cjs"
'.cjs': 'cjs',
'.js': 'esm', // obviously this shouldn't be the default here, but that's a separate discussion
'.mjs': 'esm'
}My suggestion is a field in package.json, "extensionsMap". The implementation would roughly be like this:
change https://github.com/nodejs/ecmascript-modules/blob/da0667d4b0c4fcd26b595a5af3fafd6d743cd2d1/lib/internal/modules/esm/default_resolve.js#L75 to:
const packageFormatMap = doMagicToGetThis();
// ^ this would throw if any keys in the object did not match `/^\.[^\.\s]+$/`, say
// ^ this would also either throw, or ignore, if any of the values
// in the object were not a recognized parse goal
// (ie, an existing value in `extensionFormatMap`)
const actualFormatMap = { ...extensionFormatMap, ... packageFormatMap };
let format = (legacy ? legacyExtensionFormatMap : actualFormatMap)[ext];Now, you've got a mechanism to add new extensions, override existing ones, and even set them to null, perhaps, to block them from being loaded - all per package boundary. If this were to land, I'd have no objection to a "type" or "mode" field, as either mutually exclusive sugar for this field, or, as sugar for also merging in { '.js': 'esm' }, or whichever.
Thoughts?