You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 [email protected] and [email protected]): 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:
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?
The text was updated successfully, but these errors were encountered:
We're having this problem with the lock file...
Having in the package.json postinstall: "lerna bootstrap --no-ci" doesn't work, and the hoisted dependencies aren't included in the package-lock file. We have to npm run postinstall manually to get it updated, after npm i.
In loopback-next, we have a pretty standard Lerna monorepo setup:
packages/core
andexamples/hello-world
lerna
creates symlinks)npm
to install dependenciesAn important aspect of this setup (as of
[email protected]
and[email protected]
): package-lock files MUST EXCLUDE monorepo-local dependencies, otherwisenpm ci
replaces symlinks created bylerna
with package content downloaded from the npm registry.When greenkeeper detects a new dependency version in one of the subpackages, it creates two commits:
package.json
(see e.g. loopbackio/loopback-next@279881b)package-lock.json
file (see e.g. loopbackio/loopback-next@f26e7e8)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 inlerna
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 inpackage.json
or will it update all dependencies to the latest in-range versions available?The text was updated successfully, but these errors were encountered: