Module resolution failure when using "#/" in imports

[jakezatecky]

Version

v20.11.1

Platform

Microsoft Windows NT 10.0.22631.0 x64

Subsystem

npm

What steps will reproduce the bug?

1. Create a minimal package.json that specifies the following in imports:

{
  "imports": {
    "#/*": "./*"
  }
}

2. Create two files at the project root:

// file1.js
import number from '#/file2.js';
console.log(number);

// file2.js
export default 2;

3. Execute the first script: node file1.js
4. Observe the error:

TypeError [ERR_INVALID_MODULE_SPECIFIER]: Invalid module "#/file2.js" is not a valid internal imports specifier name

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

This happens every time a key/value pair in imports has a forward slash (/) immediately following the pound sign (#).

What is the expected behavior? Why is that the expected behavior?

I would expect that file1.js is able to resolve file2.js with the specified alias. The documentation does not specify that this is an invalid setting.

What do you see instead?

TypeError [ERR_INVALID_MODULE_SPECIFIER]: Invalid module "#/file2.js" is not a valid internal imports specifier name

Additional information

There is no indication that the above configuration would not work based on the documentation. Indeed, even WebStorm's IntelliSense resolves this alias as if it would work.

Of course, setting the alias to to "#src/*": "./*" and changing file1.js to use import number from '#src/file2.js'; would work. However, I feel that would be inelegant. Imagine we have a project structure where all the files of interest are in src/, such as the following:

└── test-project/
    ├── src/
    │   ├── components/
    │   │   └── SomeComponent.js
    │   └── pages/
    │       └── SomePage.js
    └── package.json

It would be much cleaner to be able to import these files with minimal boilerplate, such as:

import SomeComponent from '#/components/SomeComponent.js';
import SomePage from '#/pages/SomePage.js';

...as opposed to having some needless additional text or specifying each directory as an alias:

{
  "imports": {
    "#components/*": "./src/components/*",
    "#pages/*": "./src/pages/*"
  }
}

[aduh95]

The spec says it should throw an error:

node/doc/api/esm.md

Lines 959 to 963 in 2f01f02

	**PACKAGE\_IMPORTS\_RESOLVE**(_specifier_, _parentURL_, _conditions_)
	> 1. Assert: _specifier_ begins with _"#"_.
	> 2. If _specifier_ is exactly equal to _"#"_ or starts with _"#/"_, then
	> 1. Throw an _Invalid Module Specifier_ error.

After a bit of digging, I found this comment that's related: #34117 (comment)

/cc @nodejs/loaders

[guybedford]

Yes, this is disallowed. Instead write:

{
  "imports": {
    "#*": "./*"
  }
}

If there's a strong argument to allow these my note in that comment still stands.

[jakezatecky]

Keeping the current restriction is not much of a problem if the main documentation includes some warning or if the error message for using #/ was unique. As it stands, Node throws the generic error that applies to any failed module resolution and gives no indication that #/ itself is invalid.

[ndabAP]

A full example thanks to @guybedford:

"imports": {
    "#*": "./*"
},

import '#index.js'