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] On npm install, prepare script runs in workspaces only if no package-lock.json or node_modules are present #2900

Closed
amatissart opened this issue Mar 18, 2021 · 1 comment
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

@amatissart
Copy link

Current Behavior:

npm install runs prepare scripts in workspaces on initial install (when no package-lock.json or node_modules exist).
On subsequent npm install, prepare scripts are no longer run for workspaces.

Expected Behavior:

The presence of package-lock.json should not have an effect on the lifecycle scripts.

Steps To Reproduce:

Use this sample repository to reproduce the issue: https://github.com/amatissart/npm-prepare-issue
A single workspace packages/a is defined.

Initial tree:

.
├── package.json
├── package-lock.json
└── packages
    └── a
        └── package.json
  1. npm install
    "prepare" script runs for the root package only.
.
├── node_modules
│   └── a -> ../packages/a
├── package.json
├── package-lock.json
├── packages
│   └── a
│       └── package.json
└── root-prepare
  1. Clean up and remove package-lock.json
    rm -r node_modules/ package-lock.json root-prepare

  2. npm install with no package-lock.json
    Without package-lock.json, "prepare" scripts run for both the root package and workspaces.

.
├── node_modules
│   └── a -> ../packages/a
├── package.json
├── package-lock.json
├── packages
│   └── a
│       ├── a-prepare
│       └── package.json
└── root-prepare

Environment:

  • OS: Ubuntu 18.04
  • Node: 14.16.0
  • npm: 7.6.3
@amatissart amatissart 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 Mar 18, 2021
@basicdays
Copy link

Yeah just ran into this as well. It's preventing a scenario where a workspace package would have a bin file that needs to be transpiled first. Since the prepare script isn't being ran during install, npm install is failing because it can't find the transpiled file to link. If I remove the root package-lock.json file, then the first install will work.

@darcyclarke darcyclarke added Priority 1 high priority issue and removed Needs Triage needs review for next steps labels Apr 9, 2021
@ruyadorno ruyadorno self-assigned this May 21, 2021
ruyadorno added a commit to ruyadorno/arborist that referenced this issue Jun 16, 2021
Users expect workspaces (or regular linked deps) to run their prepare
lifecycle script on every reify, since it's often used as some form of
compilation step and should run even though that node hasn't changed.

Fixes: npm/cli#2900
ruyadorno added a commit to ruyadorno/arborist that referenced this issue Jun 25, 2021
Previously, the `node.isDescendantOf` method would only check for direct
parents of that node, this may cause unexpected side effects on build
ideal tree and reify when working with linked dependencies.

This change modifies it so that `node.isDescendantOf` now looks at
`node.resolveParent` (making sure `fsParents` are included in the
lookup) to determine wether that node is a descendant of another.

This also made it possible to refactor the logic that checks for an
`external` dep in build-ideal-tree to use `node.isDescendantOf` instead
of a regex check in the realpath of the link.

Relates to: npm#290
Relates to: npm/cli#2900
ruyadorno added a commit to ruyadorno/arborist that referenced this issue Jun 25, 2021
Previously, the `node.isDescendantOf` method would only check for direct
parents of that node, this may cause unexpected side effects on build
ideal tree and reify when working with linked dependencies.

This change modifies it so that `node.isDescendantOf` now looks at
`node.resolveParent` (making sure `fsParents` are included in the
lookup) to determine wether that node is a descendant of another.

This also made it possible to refactor the logic that checks for an
`external` dep in build-ideal-tree to use `node.isDescendantOf` instead
of a regex check in the realpath of the link.

Relates to: npm/cli#2900
ruyadorno added a commit to ruyadorno/arborist that referenced this issue Jun 25, 2021
Users expect workspaces (or regular linked deps) to run their prepare
lifecycle script on every reify, since it's often used as some form of
compilation step and should run even though that node hasn't changed.

Fixes: npm/cli#2900
ruyadorno added a commit to ruyadorno/arborist that referenced this issue Jun 25, 2021
Users expect workspaces (or regular linked deps) to run their prepare
lifecycle script on every reify, since it's often used as some form of
compilation step and should run even though that node hasn't changed.

Fixes: npm/cli#2900
ruyadorno added a commit to ruyadorno/arborist that referenced this issue Jun 25, 2021
Users expect workspaces (or regular linked deps) to run their prepare
lifecycle script on every reify, since it's often used as some form of
compilation step and should run even though that node hasn't changed.

Fixes: npm/cli#2900
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