Transition Path Problems For Tooling

[bmeck]

Just tracking tooling encountering issues with what we have been rolling out, please add more as they are seen for gathering overall impact:

issue	resolved	summary
eslint/eslint#12319	❌	Always used require() and .js now errors for type: "module"

[guybedford]

.js-based script config files is a really important class of bug - it could be worth having a dedicated issue for this one.

[guybedford]

(this will affect most tools!)

[devsnek]

we could also just get rid of type: module, assuming we want people to depend less on package.json magic, not more

[evanplaice]

BTW, this works flawlessly in 12.0. The newer (ie better) package boundary detection is throwing the error.

Semantics feel off. The consumer (ie CJS) is consuming a module (ie ESM) that exists outside of it's package boundary. Shouldn't the package type constraint be based on the consumer not the consumed?

Anyway, w/ a 1-line patch to eslint giving the config a .cjs extension works flawlessly.

---

we could also just get rid of type: module, assuming we want people to depend less on package.json magic, not more

This breaks browser interop for pure ESM packages.

Using .mjs for ESM breaks the most tools build to write ES6+. Outside the Node ecosystem .js and ESM are one-and-the-same.

[ljharb]

That’s not entirely accurate; for example, in the babel ecosystem, everything is either a script or a module based on config, not file extension. Since nothing but node yet parses JS based on file extension, what .js means everywhere else is “i have no idea which parse goal to use yet”.

[devsnek]

I definitely didn't intend to start any arguments about extensions, I was just hoping to get in some ideas about various directions to go with ecosystem feedback. best to think of breaking changes now before we unflag.

[GeoffreyBooth]

This isn’t really a breaking change for the tool, because the user has opted into the new mode by setting type: module. The tool just doesn’t support that mode yet. Until the tool is updated, the user can simply take out type: module (or stop using that tool).

And while the user waits for the tool to be updated, they can keep using CommonJS or ESM as they do now, via esm or Babel or whatever. I’m not convinced that nodejs/node#29732 is really necessary.

There are going to be lots of tools that won’t fully support ESM mode in Node for quite awhile, beyond just require of .js inside type: module. Until we get loaders completed, code instrumentation or mocks won’t work, for example. There’s going to be a lengthy period where users will have to choose between ESM (whether via type: module or ESM more broadly) and various tools that they may want to use.

[weswigham]

I’m not convinced that nodejs/node#29732 is really necessary.

I agree - the resolver under a type: module modifier is explicitly experimental right now, so this becoming an error isn't a "new break", it's just how it should be in the experimental feature - and any pain points using type: module with tools brings up are likely other shortcomings in our current interop story.

[weswigham]

Is nodejs/node#29732 getting fast tracked because of a resolution at the meeting that I missed? Or do some of the core devs just feel that strongly about it?

[guybedford]

@weswigham all discussions and decisions are as made publicly there, there have been no side agreements. If you disagree with fast tracking or merging it behind the flag we can certainly reconsider, my primary goal was just to avoid shipping frictions to the ecosystem before we are 100% certain about it, to avoid unnecessary concern / issues for users. I see it as more of a courtesy than anything else.

[guybedford]

(this issue was not discussed at the last meeting, because we were not yet aware of the compatibility case)

[weswigham]

I just wanted to know if it'd been discussed in the WG at all (and wasn't sure since I'd missed Wednesday's meeting), since it's a slight walk-back of what'd already been merged (and i thought part of the reason for merging it was to see what kinds of issues cropped up).

I definitely asked if it should have been behind a flag when it was first added, and I still do agree enough with it having been unflagged, provided one believes that using type: module in your package.json right now implicitly opts you in to experimental behavior (regardless of node flags). If that's not perceived to be the case, I imagine we're going to have some degree of trouble shipping type: module at all, I'd wager.

[guybedford]

@weswigham as I say it is as a courtesy - we want to encourage experimentation of type module, and we don't want to cause unnecessary frictions in doing that, unless we are 100% it is those frictions we want to ship. So it's not so much about whether it is breaking as whether this is the story we want users to be dealing with. Personally I think it is still debatable whether this should be an error or a warning or similar.

[weswigham]

I was under the impression that this was expected - when you have type: module set, every .js file in scope is a module, and that includes config files. I, at least, was under no other illusions. Tools don't currently load module-based config files, so, y'know, those tools aren't going to work yet. There are no APIs for them to work yet, really. There are certainly some things we could do to make the story better (like require of esm just working, rather than erroring), or failing that TLA and dynamic import alongside package.json probing should allow those tools to support module-based configuration (with async APIs T.T).