I definitely agree that there is an ambiguity here and that we need clear definitions: I also don't know what "multi-mode" means.
I started to work a bit on the terminology issue but did not get around finishing it. Glad that you're going over these issues and working on it.

At the moment, I consider the "dual-goal" feature to be better defined. The feature in this use case mixes many things: WASM support, browser compat and progressive migration.

Here is how I see it:
At the dependency graph level there are only two kinds of modules: ESM and CJS, and there only two import mechanisms: CJS require and ESM imports.
If you include the "I don't know/any" case, it makes 3³ = 27 cases for each edge of the dependency graph: consumer module kind, import mechanism, dependency module kind. "dual-goal" works at this level.
For example:

"Agnostic ESM consumer" can be defined as supporting "Any consumer kind, ESM import mechanism, unknown dependency kind" (and having the possibility to get the same value).
"require in ESM" can be defined as "ESM consumer, CJS require mechanism, any dependency kind"

Now, going from a blob to a module is a distinct problem. There are many file types: application/node, text/javascript; goal=esm, application/json, application/wasm, .node files, JS with some new goal, etc. but ultimately they all reduce to acting either as ESM or CJS modules. It involves disambiguating JS files and extension-less files.
I consider "multi-mode" to be at this level: supporting more file type or JS parse goals.

"dual-goal" seems to be relatively wide-spread but I am not convinced this is the best term because the "goal" only makes sense for JS files but the use case also covers a consumer importing a library implemented either as a .node (CJS-like) or .wasm (ESM-like) file.

"multi-mode" seems more fuzzy and unless we define it clearly somewhere, I also consider it confusing and would prefer to use "support WASM and additional JS goals", and qualifying it as needed ("such that it works out of the box in browsers", "such that it is an implementation detail", etc.)

Support packages consisting of both ESM and CJS internally.

Support loading a package as either ESM or CJS
(1) seems like it is covered by Feature: Mixed module types within app/module; gradual migration from CommonJS to ESM #99.
(2) may even be covered by "consumer agnostic imports".

Agreed for 1, ok for 2 based on the context of this discussion.

Uh oh!

Feature: Multi-mode packages #94

Description

Metadata

Metadata

Assignees

Labels

Type

Fields

Projects

Milestone

Relationships

Development

Issue actions