[enhanced-resolve] imports field: internal intentional feature or spec deviation?

[stormslowly]

Hi! I'm working on rspack-resolver, a Rust port that aims to align with enhanced-resolve's behavior. While syncing features, we noticed a behavior difference between enhanced-resolve and Node.js in how the imports field handles non-relative targets (bare specifiers).

The Difference

In ImportsFieldPlugin.js, after resolving the imports field mapping, non-relative targets (those not starting with .) are sent to the internal-resolve hook:

// ImportsFieldPlugin.js - default case (non-relative targets)
const obj = {
  ...request,
  request: path_,
  relativePath: path_,
  fullySpecified: true,
  query,
  fragment,
};
resolver.doResolve(targetPackage, obj, ...); // targetPackage = "internal-resolve"

The internal-resolve hook re-enters the full resolver pipeline (parsed-resolve → described-resolve → raw-resolve → normal-resolve → ...), which includes the internal hook that processes #-prefixed specifiers again.

In contrast, the Node.js spec uses PACKAGE_RESOLVE(target, packageURL + "/") in PACKAGE_TARGET_RESOLVE step 1.2, which only resolves bare package names via node_modules lookup and does not re-enter imports resolution.

{
  "imports": {
    "#a": "#b",
    "#b": "./the.js"
  }
}

Resolver	resolve("#a")	resolve("#b")
Node.js (v20)	MODULE_NOT_FOUND	./the.js
enhanced-resolve	./the.js	./the.js
rspack-resolver (follows Node.js spec)	NotFound	./the.js

Node.js fails on #a because PACKAGE_RESOLVE("#b", ...) tries to find a package named #b in node_modules, which doesn't exist. enhanced-resolve succeeds because internal-resolve feeds #b back through the full pipeline, hitting the internal hook → ImportsFieldPlugin again, resolving the chain.

For standard bare specifiers (e.g., "#c": "c"), all three resolvers agree — "c" resolves to node_modules/c/index.js regardless of the mechanism used.

Question

Is the use of internal-resolve (instead of PACKAGE_RESOLVE) an intentional enhanced feature of enhanced-resolve? Or is it an unintended spec deviation?

Understanding this would help us decide the correct behavior for rspack-resolver — whether we should replicate internal-resolve semantics for full compatibility with enhanced-resolve/webpack, or stick with Node.js spec behavior.

Thank you for your time!

[alexander-akait]

@stormslowly Hello, looks like it is a spec deviation, imports resolution was written a long time ago when this behavior wasn't clearly defined, so we made it that way. Now there's a clear description of how we should behave, so we should fix it

[xiaoxiaojx]

Thanks for the feedback — fix in PR webpack/enhanced-resolve#503