Wesley Wigham

> you’ll see that the CommonJS 'coffeescript' has a lot more things attached to it than just compile; Y'all should fix that. People will come to depend on those privates...

> One way we can limit the risk of developers screwing up their migrations is to have a CommonJS dependency only receive CommonJS versions of its dependencies. In current Node,...

@SMotaal cjs consumers don't expect to use "live bindings" - they're a form of value-as-a-mutable-reference that actually doesn't make much sense. Take this code: ``` const {readFileSync} = require("fs"); callIntoOtherCode();...

> The call to require() fails with a syntax error whereas it becomes ERR_REQUIRE_ESM if I rename index.js to index.mjs. Is this behavior intended? Slightly more full answer: Yes and...

Would it be improper to arrange loaders like a middleware stack, where when you have loaders 1...N, using `import` in loader `N` invokes loader `N-1`, which, if it uses `import`,...

> 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...

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?

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...

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,...

> If we can at least avoid that hazard, what hazard is left? The hazard is that `require("path/to/esm-module")` shouldn't ever be parsed as cjs. And `require("module-with-type-module/eslint.config.js")` is, by all rights,...