Should node imply ESM when importing via Export Map aka Subpath Exports?

[mattfysh]

See reproduction: https://github.com/mattfysh/node-subpath-exports

I would assume that when the top-level package does import 'pkg', and the import specifier is resolved via the export map in node_modules/pkg/package.json under the "import" condition, that the imported module should be assumed to be ESM

I believe it should be assumed to be ESM because of the condition under which it was imported.

Instead I get this error:

/node-subpath-exports/node_modules/pkg/main.esm.js:1
import util from 'util'
^^^^^^

SyntaxError: Cannot use import statement outside a module

[aduh95]

Ping @nodejs/modules

I believe it should be assumed to be ESM because of the condition under which it was imported.

"import" could resolve to a JSON or WASM module, it would be wrong to assume it's always ECMAScript IMHO.

[mattfysh]

This is the same example that @aduh95 posted earlier, and my response is that this type of export map is self-contradictory if you respect the explicit semantics carried by "import" and "require".

[aduh95]

The point being: resolving a specifier under condition=import should carry different semantics to resolving a specifier under condition=require.

I understand why you may think that, but also things are so much simpler if we decide that not.
The current implementation ensures that the parsing goal of a .js file is always explicit. Your proposal removes that guarantee for very little benefit.

I think what you want to do is to move your exported ESM file in a subfolder folder and add a package.json containing { "type": "module" }.

// package.json
{
 "exports": {
   ".": {
     "import": "./dist/esm/pkg.js", <-- condition=import
     "require": "./dist/pkg.cjs.js" <-- condition=require
   }
 }, ...
}

// dist/esm/package.json
{ "type": "module" }

If you feel strongly about that, you could set up a loader hook (still experimental) to implement your proposal.

[mattfysh]

It's a shame that /dist/esm/package.json is required, when module type can safely be determined by the conditions within the export map, but I will respect that this is where we disagree.

For reasons that I do not understand, there seems to be a will to accommodate that a file resolved under the export map, in an explicit and author-specified condition=import route, can be a CJS module.

[ljharb]

@mattfysh here's another valid example, that must be valid to allow seamless composition of export map features:

"exports": {
  "./a": {
      "import": {
         "require": "./x.js"
       }
    }
}

is this ESM or CJS?

[bmeck]

I'm just here to state conditions are no applied to the target, conditions are parameters of the loaders. Currently this is like the following in pseudocode:

// imagine load() ~= import and require in an abstract sense
function load(specifier, dependentLocation) {
  const target = find(specifier, dependentLocation, ['node', 'require' | 'import']);
  // ...
}

If we instead make conditions properties of the target

// imagine load() ~= import and require in an abstract sense
function load(specifier, dependentLocation) {
  const target = find(specifier, dependentLocation, ['node', 'require' | 'import']);
  if (target.usedConditionsToLoad.includes('import') && target.package.type == null) target.format = ...
  // ...
}

It causes a variety of confusions, such as:

• using resolution that doesn't go through export maps such as absolute locations (passing import.meta.url in particular causes this). in such cases usedConditionsToLoad would be empty always.
• to avoid that you need to know how to reverse lookup the conditions from a target (idk honestly unless we start doing full crawls of fs resolutions w/ early errors). per examples above this basically requires each target to be statically known and problems like having both an export and import pointing to the same file would have to cause early errors. This is a fair bit more work to do per load.

These manifest in ways like the ambiguity of not knowing what format a file is statically. In general, to avoid these categories of problems, the loading mechanism provides data that is parameterized but does not modify the target is the point.