[BUG] npx doesn't work when in child workspace

[felipecrs]

Current Behavior:

If I run npx <binary> of a binary installed by a child's package.json, it doesn't find the binary as npm v7 now install the binaries under the parent node_modules.

Expected Behavior:

This used to work, as there was no workspaces concept before and therefore all the projects were linking binaries to their node_modules.

Steps To Reproduce:

Should be simple.

Environment:

Suggestion

I think this should not be fixed by npx itself, but instead, npm should create symlinks under the children's node_modules/.bin at least for the packages referenced in the children's package.json.

[ljharb]

I don't think this is something that was ever truly reliable. If you're expecting to run a local binary, it should be a direct dep/devDep.

If anything, it's a bug that bins are created at all for transitive deps.

[felipecrs]

This can be replicated:

1. Open my repository: https://gitpod.io/#https://github.com/felipecrs/megatar
   • It has a package.json in the root, and another in the website subfolder.
   • docusaurus is set as dependency in the website folder.
   • docusaurus is NOT set as dependency in the root project
   • website is in the list of workspace of the root project
   • Gitpod will run npm install automatically in the root project, but feel free to git clean -fdx and run npm install by yourself
2. Run cd website; npx docusaurus --version
   • It will fail: docusaurus is not in website/node_modules/.bin but in node_modules/.bin (from the root folder).

[ljharb]

Ah, in the context of workspaces, i see what you mean. The bins should surely not be hoisted to the parent, even if the module itself is.

[darcyclarke]

Can replicate & we're discussing internally how to fix this bug

[felipecrs]

I have some ideas:

1. Make npx look up for node_modules/.bin folder up to the root folder /
2. Create a symbolic link of the root's bin folder: website/node_modules/.bin -> ../node_modules/.bin
3. Create a symbolic link of the modules defined in the child workspace: website/node_modules/.bin/docusaurus -> ../node_modules/.bin/docusaurus (seems to be the best approach to me)
4. Install the bins only to where they belong, instead of installing docusaurus on the node_modules, install to website/node_modules. Seems reasonable, but it would be too bad as I would lose the ability to run npx docusaurus from the root folder

[ljharb]

The last option makes the most sense to me; if you wanted to run a bin from the root it'd be in the root's package.json.

[felipecrs]

What if there are two child projects which has docusaurus as dependencies? Would be good if npm would be smart enough to download it once (if the version constraints match of course), instead of downloading it twice in each repo.

That's why I think the third option would be better than the fourth.

[ljharb]

Hoisting the dependency itself would make sense - but not the bin.

[felipecrs]

In a monorepo, I would like to have semantic-release defined in the root project, so it would be available for all the child projects, even the binary because I would need to run npx semantic-release in all the child projects.

The only solution which would match this requirement would be 1 and 2. But now I thought in a new one which builds on 4:

5. Install the bins only to the project they belong, instead of installing child's binaries on the root's node_modules/.bin, install to child's node_modules/.bin. Exceptionally for the bins defined in the root project, install the bins into root's node_modules/.bin and create symbolic links of all the binaries from the root project to all the child projects (unless they collide, of course).

Now, this is the one which makes more sense to me.