Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

imports allows and ignores #name/ in package map #40579

Open
evanw opened this issue Oct 23, 2021 · 1 comment
Open

imports allows and ignores #name/ in package map #40579

evanw opened this issue Oct 23, 2021 · 1 comment
Labels
esm Issues and PRs related to the ECMAScript Modules implementation.

Comments

@evanw
Copy link

evanw commented Oct 23, 2021

Version

v17.0.1

Platform

Darwin Evans-MacBook-Pro.local 20.6.0 Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64

Subsystem

No response

What steps will reproduce the bug?

Here's a simple example:

$ cat test.mjs
import * as x from '#x'
console.log(x)

$ cat package.json
{
  "imports": {
    "#x": "#what/foo/y.mjs"
  }
}

$ cat node_modules/foo/y.mjs
export let y = true

$ node test.mjs
[Module: null prototype] { y: true }

Notice the bogus #what/ prefix that is being discarded by node.

How often does it reproduce? Is there a required condition?

Always

What is the expected behavior?

I expected path resolution to fail, at least according to the documented algorithm here: https://nodejs.org/api/esm.html#resolution-algorithm. From what I understand, it's supposed to go something like this:

  1. ESM_RESOLVE("#x", "file://.")
  2. PACKAGE_IMPORTS_RESOLVE("#x", "file://.", ["default"])
  3. PACKAGE_IMPORTS_EXPORTS_RESOLVE("#x", { "#x": "#what/foo/y.mjs" }, "file://.", true, ["default"])
  4. PACKAGE_TARGET_RESOLVE("file://.", "#what/foo/y.mjs", "", false, true, ["default"])
  5. PACKAGE_RESOLVE("#what/foo/y.mjs", "file://./")

At this point packageName should be "#what" and packageSubpath should be ./foo/y.mjs. That should then fail because there is no file called node_modules/#what/foo/y.mjs on the file system.

What do you see instead?

Somehow the #what/ prefix seems to be getting lost in the process which lets the remapping to #what/foo/y.mjs succeed. Specifically #what/foo/y.mjs behaves just like foo/y.mjs. If I'm reading the algorithm correctly, then I think node's implementation is diverging from the specification somewhere and is incorrect.

Additional information

This looks like a bug in node to me. But if it's not, it would be great to update the documentation so that other implementations of node's algorithm can be implemented correctly. I'm trying to get the module resolution algorithm in esbuild to match node and I'm not sure what to do here.

@Mesteery Mesteery added the esm Issues and PRs related to the ECMAScript Modules implementation. label Oct 23, 2021
@merceyz
Copy link
Member

merceyz commented Sep 17, 2022

Since this is labled esm could someone ping the @nodejs/modules team so we can get a clarification about what the expected behaviour is supposed to be?

unicornware added a commit to flex-development/mlly that referenced this issue Jan 24, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
esm Issues and PRs related to the ECMAScript Modules implementation.
Projects
None yet
Development

No branches or pull requests

3 participants