Scope of team

[MylesBorins]

If we plan to charter, part of the process will be deciding on the scope of the team, and what we will be explicitly asking the TSC to take responsibility for.

While the original scope of this group was ESM, it is very likely that part of (or potentially all) the CJS implementation may be required to be in the scope of this group.

Let's use this thread to brainstorm

[devsnek]

i would like to see this group handling everything related to how modules of the esm and cjs variety (and whatever else?) get handled in node, as they are definitely coupled in the ecosystem

[bmeck]

I have a few topics that I would like to stick up for discussion that need to be cross module system:

• content type conflicts, namely:
  • file extension conflict resolution
  • URL affects for things like blob: / text: and the affects on being in conflict with loader hook results
• loader hooks (per --loader hooks for require() #6)
• integrity checks as a future proofed need

[zackschuster]

building on from @bmeck, from what i've seen so far, here are the major asks:

• transparent interop between ESM + CJS w/o a build step
• transparent interop between Node/Browsers when running ESM
• allow consumers to intercept/override require
• fallback mechanism for legacy modules to be converted to ESM without losing access to scoped variables

[MylesBorins]

So I think that the high level take away at this point is that our scope is going to be both ESM + CJS. The group may in turn take responsibility for all of require, the module specifier resolution algorithm, etc.

I do have slight concerns about how quickly this could expand and move away from the intent and timely work. Would it perhaps make sense to scope to ESM + interoperability with CJS?

[zackschuster]

given that merely accepting a new file extension has set everyone back by god-knows-how-long, i'm inclined to say yes, we should define an extraordinarily limited MVP or the group may never ship.

(not saying .mjs is bad, just that relatively "small" things could easily trip us up)

[WebReflection]

not saying .mjs is bad

I think you can say that, we're here because nobody liked that.
Not bad as workaround, bad as solution for the majority of the JS community.

we should define an extraordinarily limited MVP or the group may never ship

amen.

[WebReflection]

Would it perhaps make sense to scope to ESM + interoperability with CJS

It's the only way forward if we want to even think about shipping in v10.

[bmeck]

I think you can say that, we're here because nobody liked that.

I think we should agree to disagree on a variety of things.

[zackschuster]

@WebReflection i'd agree, .mjs has a lot of problems (my favorite is breaking file previews) but i don't want to discount people who prefer that approach for their own reasons. (...oh hi there @bmeck, right above me)

beyond that, being "realistic" i'm guessing it'll still be an uphill battle for an alternative proposal to succeed, if only because ".mjs works" and therefore there's likely a massive amount of pressure from interested parties in seeing that move forward regardless -- which would also mean there's a very real possibility that, even if the group ships, steering may decline the product.

for obvious reasons i consider that a prominent risk to avoid.

[WebReflection]

it's demonstrated, and easy to demonstrate, that .mjs doesn't work. It's a convenient workaround, not a migration pattern, neither a solution. Nobody writes extensions in Node, which is first AFAIK agreed point of this team: make ESM that works in browsers work out of the box in NodeJS.

Pure ESM in browsers is import mod from "./file.js" and it works already, is not something that needs to ship, differently from node, rather something already shipped, deployed, and working without any issue.

The hooks on web are on loading, like type=module, not on mime-type different from .js or file extensions, so there's no need to go down that ugly file extension road what won't seamlessly work on the Web where ESM is already almost everywhere without any flag.

So, ESM + interoperability with CJS seems to be right team scope, and we should define an extraordinarily limited MVP the only way this group of people could make sense.

[bmeck]

@WebReflection we completely disagree on these topics and conclusions.

[WebReflection]

there's nothing to disagree, I've presented always facts, never opinions. When you'll point at me at a well established NodeJS project that uses file extensions in CommonJS or transpiled fake ESM then you might have some counter fact to talk about. until that, I use already unpkg.com CDN to deliver pure ESM and being unpkg.com a mirror of npm my modules work already in ESM capable environments (SpiderMonkey, JSC) and are also transpiled to CommonJS for Node.

Basically I already experience the goal of this team and I can say it works already.

Same goes for everyone else that used @std/esm without even needing full file resolutions on ESM.

[MylesBorins]

@WebReflection userland and platform implementations have extremely different requirement. Your statement regarding what can already be accomplished with tooling is proof that a vibrant ecosystem can come up with great solutions

Here's a scope I would like to make and challenge everyone to abide to

Can we please scope our conversation to explicit proposals rather than philosophy. We continue to get stuck in the weeds of implementation details and focusing on parts of the user experience that we find to not be ergonomic.

For example I would not like to ship transparent interop. That being said I think I will have a better chance of influencing the decision of what we ship by suggesting concrete changes (import.meta.require) and suggesting compromises that can work towards my goal.

This group was spun up to come up with concrete proposals that find us a path forward. If we kick this off with infighting and endless debate around implementation we will get nowhere.

[WebReflection]

FWIW I'm already pro import.meta.require (even if I've discovered you cannot actually pollute import.meta in current WebKit/Chrome browsers) and fully happy with a node --type=module equivalent.

To me that is the best deal that works with pure ESM that already works in browsers and works with CJS modules.

Ask me if I'd like that any time you want, my answer will be always yes.

[WebReflection]

To strength the feasibility:

js52 -m PATH or js52 --module=PATH already works with .js files in every Linux shell.

jsc -m PATH or js52 --module-file=PATH already works with .js files in every macOS shell.

NexusJS which is a competitor (big selling point?) already works with everything as expected (and .js is the expected for both ESM or CJS).

Browsers <script type=module> already work with ESM too. text/javascript or application/javascript are valid ESM.

We miss interoperability with CommonJS. While all the mentioned environments already have a pure ESM module that brings CJS in hose env, NodeJS could pave the road for import.meta.require which as suggested is static analysis friendly.

With only these two as proposal and goals we restrict our scope and we can ship for v10.

With anything bigger than 2 or 3 bullet points and 3 months I don't think there's anything we can do for v10 so we can take all the time we want for v12 (undesirable, imo)

[MylesBorins]

@WebReflection the deadline for v10 is closer to 9 - 27 months. We can remove the flag any time and land as semver-minor. Only semver major changes against core will have that cut off (and it actually is more like 2 months)

Can we please keep this issue on track though... focusing on scope, not implementation

[ljharb]

For example I would not like to ship transparent interop.

For me, transparent interop is a critical requirement.

[evanplaice]

Can we nail down some broad milestones that can be later refined into specific changes? Much of the work that needs to be done requires additional research, exploration, and discovery.

This has been relocated to Roadmap (preliminary draft)

[mcollina]

I think loading a CJS module from ESM is something critical for 10.0.

[MylesBorins]

@evanplaice could you open a separate issue regarding roadmap? I would like to keep this issue scoped to... scope 😊

[ljharb]

I also think that "It does not include ESM<->CJS interop" is unacceptable for any unflagged implementation.

[evanplaice]

@MylesBorins Yes, I'll move the body of the above comment to a separate issue.

@ljharb Noted, I removed that from the list. If you have more feedback see roadmap(prelimnary draft)

[MylesBorins]

going to close this for now. We can revisit this (in a fresh thread) when we have a better idea of the exact work we will be doing