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

[BUG] npx/npm exec don't work in child workspace when using --no/--no-install and --package #3520

Closed
1 task done
rossng opened this issue Jul 6, 2021 · 4 comments · Fixed by #4643
Closed
1 task done
Assignees
Labels
Bug thing that needs fixing Priority 1 high priority issue Release 7.x work is associated with a specific npm 7 release

Comments

@rossng
Copy link

rossng commented Jul 6, 2021

Is there an existing issue for this?

  • I have searched the existing issues

Current Behavior

I am using NPM workspaces. I am running a command of the format:

npm exec --no --workspace=my-workspace --package @graphql-codegen/cli -- graphql-codegen --config codegen.js

It fails with a rather terse npm ERR! canceled.

This is related to a previous issue #2826. The bug was partially resolved by @ruyadorno in npm/libnpmexec#2. However, looking at the commit, it seems that the fix was only applied inside the if (needPackageCommandSwap) block. This only executes if no --package option has been specified.

If --package is specified, then the code falls through to https://github.com/npm/libnpmexec/blob/a9423e441b914571ec18ad8a4496a3ecf2f500e2/lib/index.js#L153. It will then try to install the package (even though it's already available locally). However, if --no[-install] is specified, it will simply throw an exception instead.

Expected Behavior

The npm exec and npx commands should work when used in a workspace with the --package and --no[-install] options.

Steps To Reproduce

No response

Environment

  • OS: Windows
  • Node: 16.4.0
  • npm: 7.19.1
@rossng rossng added Bug thing that needs fixing Needs Triage needs review for next steps Release 7.x work is associated with a specific npm 7 release labels Jul 6, 2021
@nlf
Copy link
Contributor

nlf commented Mar 8, 2022

we've made a lot of changes to workspaces in the last several months, can you test this in npm 8.5.3 and let us know if it's fixed?

@rossng
Copy link
Author

rossng commented Mar 8, 2022

I moved my original project to pnpm in the end, so I reproduced this problem by:

I still see the same output:

npm ERR! canceled

@wraithgar wraithgar added Priority 1 high priority issue and removed Needs Triage needs review for next steps labels Mar 15, 2022
@wraithgar
Copy link
Member

That repo really helps, thanks.

Logs don't give much info

33 timing command:exec Completed in 391ms
34 verbose stack Error: canceled
34 verbose stack     at exec (/Users/wraithgar/.nvm/versions/node/v16.14.0/lib/node_modules/npm/node_modules/libnpmexec/lib/index.js:156:17)
34 verbose stack     at async Exec.execWorkspaces (/Users/wraithgar/.nvm/versions/node/v16.14.0/lib/node_modules/npm/lib/commands/exec.js:97:7)
34 verbose stack     at async module.exports (/Users/wraithgar/.nvm/versions/node/v16.14.0/lib/node_modules/npm/lib/cli.js:66:5)
35 verbose cwd /Users/wraithgar/Development/npm/scratch/npm-ts-workspaces-example/packages/x-cli

@rossng
Copy link
Author

rossng commented Mar 16, 2022

Yeah, the log output is no use at all. But I found it easy to step through with the debugger when I first encountered it - looks like the relevant code hasn't changed much since.

@ruyadorno ruyadorno self-assigned this Mar 28, 2022
ruyadorno added a commit to ruyadorno/cli that referenced this issue Mar 30, 2022
Fixes the proper path location to use when targetting specific
workspaces.

Makes it so that libnpmexec is always reading from the
Arborist actual tree instead of reading `node_modules` from
the file system when retrieving local package data.

Fixes: npm#3520
Relates to: npm#4619
Relates to: npm/statusboard#403
ruyadorno added a commit to ruyadorno/cli that referenced this issue Mar 30, 2022
Fixes the proper path location to use when targetting specific
workspaces.

Makes it so that libnpmexec is always reading from the
Arborist actual tree instead of reading `node_modules` from
the file system when retrieving local package data.

Fixes: npm#3520
Relates to: npm#4619
Relates to: npm/statusboard#403
ruyadorno added a commit to ruyadorno/cli that referenced this issue Mar 31, 2022
Fixes the proper path location to use when targetting specific
workspaces.

Makes it so that libnpmexec is always reading from the
Arborist actual tree instead of reading `node_modules` from
the file system when retrieving local package data.

Fixes: npm#3520
Relates to: npm#4619
Relates to: npm/statusboard#403
ruyadorno added a commit to ruyadorno/cli that referenced this issue Mar 31, 2022
Fixes the proper path location to use when targetting specific
workspaces.

Makes it so that libnpmexec is always reading from the
Arborist actual tree instead of reading `node_modules` from
the file system when retrieving local package data.

Fixes: npm#3520
Relates to: npm#4619
Relates to: npm/statusboard#403
ruyadorno added a commit to ruyadorno/cli that referenced this issue Apr 11, 2022
Fixes the proper path location to use when targetting specific
workspaces.

Fixes: npm#3520
Relates to: npm/statusboard#403
ruyadorno added a commit to ruyadorno/cli that referenced this issue Apr 19, 2022
Fixes the proper path location to use when targetting specific
workspaces.

Fixes: npm#3520
Relates to: npm/statusboard#403
lukekarrys pushed a commit that referenced this issue Apr 19, 2022
Fixes the proper path location to use when targetting specific
workspaces.

Fixes: #3520
Relates to: npm/statusboard#403
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug thing that needs fixing Priority 1 high priority issue Release 7.x work is associated with a specific npm 7 release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants