Mode: esm proposal

[guybedford]

I'd like to add the "mode": "esm" proposal to this weeks agenda as a complementary proposal to the import file specifier resolution proposal and the package export maps proposal.

I've written up a motivation about how it fits in to these existing proposals at https://github.com/guybedford/ecmascript-modules-mode.

Most of the existing behaviours of both of these specs can remain, it just adds a little more orthogonality to the primitives.

There are still a few edge cases to be discussed and worked out as well, but the overarching approach seems very complementary to me.

[devsnek]

there are a lot of things that fall under the umbrella of "esm" that aren't source text. should we use mimes? our own names? something else? why not use a loader? etc...

[GeoffreyBooth]

If I could add, this proposal is only about the UX of how the configuration should be in package.json files. The actual functionality is covered by the other two proposals. If you haven't had a chance to review those yet, now would be a great time.

@guybedford can give a demo of the implementation of those proposals this week.

[ljharb]

As a heads up, I’m not a fan of any UI in package.json that isn’t a map of parse goals (ideally represented via extension, potentially via mime or enum) to extension - anything that enshrines “esm” in a way that precludes the many other future module formats (wasm, html, etc) isn’t imo going to be viable.

[bmeck]

I'm not caring so much about specific strings, but I would like a shorthand for pulling in maps. Maps of formats could live in other packages as they grow or are updated, and it seems ok to include the default mappings that Node.js ships with somehow. I don't want to limit the UX to manually listing all mappings in every package rather than letting the UX pull from a set of mappings that could be shared across multiple packages. Using a field with the same UX as "mode" seems to satisfy that desire.

[ljharb]

Making mappings shareable seems like a bit of circularity - defining how to import in an importable file.

[bmeck]

@ljharb how is this a problem? Circular deps are supported, this is a similar situation.

[ljharb]

You potentially wouldn’t be able to resolve the file properly in order to figure out how to resolve the file.

[bmeck]

@ljharb if you link to typescript/mappings (or w/e) typescript/mappings would be subject to its own package scope of resolution types. In order to get a circularity you need 2 modules a and b where the path to a's mappings points to b's mappings which point to a's:

/a/package.json#formats => /b/formats
/a/package.json#exports {formats => b/formats}
/b/package.json#exports {formats => a/formats}

Banning this circularity is simple and the circularity itself is hard to even achieve.

[ljharb]

And what if it’s a relative import in your own project, that would thus be governed by the mapping itself?

[bmeck]

@ljharb probably under same idea as loaders, paths to loaders are not intercept-able due to thrashing issues like this.

[ljharb]

That suggests that the mapping file might change its own parse mode (from later imports) after it’s first imported?

[bmeck]

@ljharb if the formats allow to be in multiple formats yes, the same issue exists for loaders. A loader cannot be in a .jsx file for example, even if it enables loading .jsx

[ljharb]

For adding extensions sure - but if a .js CJS file changes it so that .js files are not CJS?

[bmeck]

@ljharb loader.js would be assumed to be CJS by default but could make all references to .js files resolve to ESM instead of CJS. Meta-programming needs to use the root form of loading mechanisms, otherwise they are not able to be reasoned about. Similarly ServiceWorkers do not instrument themselves, even though they manipulate the main thread.