Clarification needed for package lock files

[simllll]

There are a lot of open and closed issues around regarding lock files (mainly I was looking for package-lock.json issues with npm).

I'm not quite sure if this is intended, or if it is a bug.. but I do not get any lock file in my sub packages. I'm hoisting all the dependencies though, which would actually make sense to me that it is hard for any kind of lock file to get generated.

So first I would like to clarify if this is the case: does hoisting prevent package lock files to get generated in my sub packages? I only have one in my root folder.

The problem with this is that I just hoist for development purposes, as soon as the CI pipeline kicks in, all the dependenices get build & published, and afterwards a npm install in the "sub directory" is executed... but now this npm install has no package-lock to refer to. This turned out already badly several times, as suddenly a wild new package appears which breaks something in the current build.

Is there any better approach? How do you maintain your lock files for the sub folder guys? Or how could I solve my issue to "reference" the package-lock file from the root folder even though I'm running a npm install in a sub folder?

Expected Behavior

• There should be an approach that let us use the package lock files.
• Improve documentation for hoisting, that there is only a package lock file in the root folder.

Current Behavior

• There is no package-lock file in each package
• there is only one package lock file in the root folder
• this package lock file cannot be used for npm installs in sub packages.

Steps to Reproduce (for bugs)

1. create monorepo
2. add two packages with at least one external dependency
3. run lerna bootstrap --hoist --force-local
4. no package-lock in sub folders / only in root

lerna.json

{
	"packages": ["packages/*", "services/*"],
	"version": "independent",
	"command": {
		"publish": {
			"message": "chore(release): publish"
		}
	},
	"hoist": true,
	"forceLocal": true,
	"conventionalCommits": true,
	"reject-cycles": true,
	"ignoreChanges": [
		"**/__tests__/**",
		"**/*.md",
		"**/*.tmp"
	]
}

Context

Ran into several deployment issues due to the missing package-lock file.

Your Environment

linux / CI build

Executable	Version
lerna --version	3.16.4
npm --version	6.11.3
node --version	v12.6.0

[ELLIOTTCABLE]

I'm running into this, too.

My current approach, painfully, is to manually npm install in each of the sub-packages, after lerna bootstrap, when adding new packages / updating versions. This gives each package a chance to update its "local lockfile."

Notably, if you have packages which depend on other, unpublished packages, this is going to be … extremely not-fun:

1. with blah-unpublished included in the deps of widget, lerna bootstrap in the root
2. manually remove blah-unpublished from the deps of widget
3. manually npm install in ./packages/widget, so that widget's package-lock.json includes everything except blah-unpublished
4. manually re-add blah-unpublished to the deps in widget
5. run lerna bootstrap --ci in the root.

yikes!

[massens]

We have exactly the same issue as @simllll

It seems reasonable that there should be a workflow where you have complete control over which dependencies are used through lock files, and you're not exposed to new packages breaking deploys. Maybe we're missing something?

[Carduelis]

I was very wondered when I redo a lerna bootsrap the deleted file did not appear after I deleted package-lock because of a lot of git conflits where there when I did a cherry-pick.

My root package.json has a 10-15% of all dependency sections in all packages. Therefore all other packages could be replaced and no one notice it.

How to solve this issue in a correct way?

[fahslaj]

Hi all, it is no longer recommended to use lerna bootstrap. The recommendation for modern version of Lerna is to rely on the workspaces functionality of whichever package manager you are using. I would suggest checking out the legacy package management page in the Lerna docs.

Older versions of Lerna that don't support workspaces are no longer supported, and alternatives to workspaces are outlined in that doc.