fix(compartment-mapper): infer module type from the import key in package.json exports

[naugtur]

• add a failing test exposing a cjs/esm compatibility issue in compartment-mapper
• fix missing inference from package.json->exports import field

The way it fixes the test is not exactly matching what node.js would do in the same situation.
Node.js loads the file in package.json->exports['./sha2'].require but Endo loads the one from package.json->exports['./sha2'].import.
All this fix is doing is correcting the module type inference for package.json->exports in general.

Changing the behavior of selecting import vs require could happen elsewhere, but it seems unimportant in Endo (until we find a package that ships breaking changes in one version across esm and cjs variants)

[naugtur]

As an experiment, I've told agent to debug this, gave it suggestions where to look and coerced a summary.

Edit: it was incorrect :D

ai debugging outcome

---

Bug Analysis: ESM/CJS Dual Package Export Resolution

Issue

The test noble.test.js fails with:

Unexpected import statement in CJS module.
at file://.../fixtures-noble/node_modules/@noble/hashes/esm/sha2.js:8:8

Root Cause

The @noble/hashes package uses conditional exports in package.json:

{
  "exports": {
    "./sha2": {
      "import": "./esm/sha2.js",
      "require": "./sha2.js"
    }
  }
}

The compartment-mapper incorrectly:

1. Selects the ESM path (./esm/sha2.js) because the "import" condition is always added to conditions
2. Parses it as CJS because package.json has no "type": "module" field

Key Findings

1. Condition Set Always Includes "import"

In node-modules.js line 789:

conditions.add('import');

This causes the "import" condition to always be present, regardless of how the package is being consumed.

2. Export Resolution Selects ESM Path

In infer-exports.js, the interpretExports() function iterates over export condition keys:

for (const [key, value] of entries(exports)) {
  // ...
  } else if (conditions.has(key)) {
    yield* interpretExports(name, value, conditions);
    break;  // Takes first matching condition
  }
}

Since "import" is in conditions and appears first in the exports object, it matches and yields ./esm/sha2.js.

3. Parser Selection Uses package.json "type" Field

In node-modules.js, inferParsers() determines the parser based on packageDescriptor.type:

if (type === 'module' || module !== undefined) {
  return { ...moduleLanguageForExtension, ... };  // js -> mjs
}
// ...
return { ...commonjsLanguageForExtension, ... };  // js -> cjs (default)

Since @noble/hashes has no "type" field, it defaults to CJS parsers.

4. The types Object Is Not Populated

The types object (which becomes languageForModuleSpecifier) should record that specific module paths should be treated as ESM. However:

• interpretExports() doesn't receive the types object
• Even inferExportsEntries() only populates types for the legacy "module" field (lines 132-137), not for conditional exports

Debug output confirmed:

Package "@noble/hashes":
  externalAliases: { './sha2': './esm/sha2.js' }
  types (languageForModuleSpecifier): {}          <-- EMPTY! Should have './esm/sha2.js': 'mjs'
  parsers: { ..., js: 'cjs' }
  packageDescriptor.type: undefined

Proposed Fix

Option A: Propagate Type Information Through Export Resolution (Recommended)

Modify interpretExports() to track when the "import" condition is matched and record the resolved paths in the types dictionary.

Changes needed in infer-exports.js:

1. Add types parameter to interpretExports():

function* interpretExports(name, exports, conditions, types) {

2. Track matched condition and populate types:

} else if (conditions.has(key)) {
  // If we matched the 'import' condition, mark resolved paths as ESM
  const isImportCondition = key === 'import';
  for (const [specifier, target] of interpretExports(name, value, conditions, types)) {
    if (isImportCondition && types) {
      types[target] = 'mjs';
    }
    yield [specifier, target];
  }
  break;
}

3. Update all call sites of interpretExports():

   • Line 72: interpretExports(name, section, conditions) → add types
   • Line 94: interpretExports(key, value, conditions) → add types
   • Line 96: interpretExports(join(name, key), value, conditions) → add types
   • Line 99: interpretExports(name, value, conditions) → add types
   • Line 144: interpretExports('.', exports, conditions) → add types

4. Update inferExportsEntries() signature if needed to pass types through.

Option B: Use File Extension as Hint

Files in /esm/ directories or with certain patterns could be detected and marked as ESM. This is less reliable but simpler.

Option C: Don't Add "import" Condition by Default

Remove the automatic conditions.add('import') and let callers explicitly specify conditions. This would be a breaking change.

Files to Modify

1. src/infer-exports.js - Main fix location

   • interpretExports() function (lines 69-102)
   • inferExportsEntries() function (lines 125-145)

2. src/node-modules.js - May need adjustments

   • graphPackages() where conditions are set (line 789)

Test Case

The existing test/noble.test.js with test/fixtures-noble/ serves as the test case:

• fixtures-noble/index.js uses require('@noble/hashes/sha2')
• @noble/hashes has dual ESM/CJS exports
• Should load ./sha2.js (CJS) not ./esm/sha2.js (ESM)

Related Code References

• src/infer-exports.js - Export inference logic
• src/node-modules.js - Package graph building and parser inference
• src/map-parser.js - Parser selection based on languageForModuleSpecifier
• test/infer-exports.test.js - Existing tests for @noble/hashes exports (passes because it only tests export mapping, not parsing)

[boneskull]

I think this looks right. Should we be doing something similar with the require key or ..?

[naugtur]

I think this looks right. Should we be doing something similar with the require key or ..?

The way the ecosystem settled, things default to cjs. (that's why the test in this PR was initially throwing an error that it found ESM syntax in CJS module)
If we need to move away from the ".js is CJS unless something states otherwise in package.json" your suggestion to collect cjs type hints becomes valid.

[changeset-bot]

🦋 Changeset detected

Latest commit: 6a4d121

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 7 packages

Name	Type
@endo/compartment-mapper	Patch
@endo/bundle-source	Patch
@endo/check-bundle	Patch
@endo/cli	Patch
@endo/daemon	Patch
@endo/import-bundle	Patch
@endo/test262-runner	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[naugtur]

Improved the changeset. Ready to merge.