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

Correctly update npm's package-lock files in Lerna monorepos #1080

Open
bajtos opened this issue Apr 12, 2019 · 0 comments

Comments

Projects
None yet
1 participant
@bajtos
Copy link

commented Apr 12, 2019

In loopback-next, we have a pretty standard Lerna monorepo setup:

  • Several packages in subdirectories like packages/core and examples/hello-world
  • We use the default strategy to resolve monorepo-local dependencies (lerna creates symlinks)
  • We use npm to install dependencies
  • Package locks are enabled at root level and in every individual package too
  • Dependencies ARE NOT hoisted, they are always installed in the package that requires them.

An important aspect of this setup (as of lerna@3.13.2 and npm@6.9.0): package-lock files MUST EXCLUDE monorepo-local dependencies, otherwise npm ci replaces symlinks created by lerna with package content downloaded from the npm registry.

When greenkeeper detects a new dependency version in one of the subpackages, it creates two commits:

Actual behavior

The commit updating package-lock.json file is incorrectly adding monorepo-local dependencies to the lock file.

Expected behavior

The commit updating package-lock.json file keeps monorepo-local dependencies out of the lock file.

Proposed solution

I assume GreenKeeper is running npm install in the package to update the lock file. This does not work in lerna monorepos.

To correctly update package locks, we are running the following two commands in monorepo's root:

lerna clean && lerna bootstrap --no-ci

I think the first command lerna clean should not be necessary in principle, unfortunately it's needed in practice - at least in my experience. (Possibly related: lerna/lerna#2015).

It makes me wonder - can Greenkeeper use the same approach?

My main concern is that I am not sure what will happen when we run lerna bootstrap --no-ci and there are more out-of-date dependencies. Will the new package lock contain updates only for the dependency that was updated in package.json or will it update all dependencies to the latest in-range versions available?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.