[BUG] Import error with install-strategy=linked and namespaced packages in a workspace

[iansu]

Is there an existing issue for this?

• I have searched the existing issues

This issue exists in the latest npm version

• I am using the latest npm

Current Behavior

The namespace is being dropped when linking workspace packages which results in them not being found when attempting to import from them.

I've made a minimal repro here: https://github.com/iansu/npm-linked-install-repro

I have two packages in a workspace in this repo:

• @iansu/package-a
• @iansu/package-b

@iansu/package-b has a dependency on @iansu/package-a

When no install strategy is specified this is what the root node_modules directory looks like:

❯ tree node_modules
node_modules
└── @iansu
    ├── package-a -> ../../packages/package-a
    └── package-b -> ../../packages/package-b

3 directories, 0 files

In this case nothing is installed in package-b's node_modules directory

When install-strategy=linked is specific this is what the root node_modules directory looks like:

❯ tree node_modules
node_modules
├── package-a -> ../packages/package-a
└── package-b -> ../packages/package-b

2 directories, 0 files

Additionally this is what package-b's `node_modules directory looks like:

❯ tree packages/package-b/node_modules
packages/package-b/node_modules
└── package-a -> ../../package-a

1 directory, 0 files

When I try to import from @iansu/package-a I get an error because neither node_modules/@iansu/package-a or packages/package-b/node_modules/@iansu/package-a exist

Expected Behavior

The contents of node_modules should include the namespace and produce a tree similar to the one produced when not using install-strategy=linked

Steps To Reproduce

1. Clone the repro
2. Run npm install --install-strategy=linked
3. cd packages/package-b
4. node index.js
5. Observe import error

If you delete node_modules and run npm install again without install-strategy=linked you will not get the import error

Environment

• npm: 9.4.1
• Node.js: 16.15.0
• OS Name: macOS
• System Model Name: M2 MacBook Air
• npm config:

; "user" config from /Users/iansu/.npmrc

//registry.npmjs.org/:_authToken = (protected)
init-author-email = "ian@<domain>"
init-author-name = "Ian Sutherland"
init-license = "MIT"
init-version = "0.0.0"

[justinfagnani]

It's not just the namespace that's omitted... the symlink in node_modules/ is being named after the workspace directory instead of the workspace's package name.

I have some packages with a prefix for the names, like internal-foo, but the folder name is just foo. The symlink is written as just foo causing imports of internal-foo to fail.

[gaomeng1900]

Exactly. The symlink should be named after the full package name. Now it's named after the forder name of each workspace. Which is irrelevant.

[justinfagnani]

So install-strategy=linked is completely unusable for anyone working with scoped packages with this bug. Any chance of it getting prioritized?

Other than this, linked installs look like they solve a lot of problems for us and I'm excited to try it out when it's ready.

[justinfagnani]

Is there any hope of getting this addressed or prioritized? install-strategy=linked is just completely broken in the way it creates symlinks.

[iSuslov]

Indeed it's very strange bug and should be prioritized.

[4leite]

EDIT: The workaround a posted seems to result in deleting the folder contents on 'npm i'
so don't do this: I renamed from packages/utils to packages/@repo__utils

[Ben-Barron]

Hi, just following up, is this going to be looked at in the near term?

[jdfm]

I'm also running into this.

The version of npm we're using is 10.8.1.