[Question] [Yarn] Should package lockfiles be committed when using yarn?

Context

Setting up a greenfield project with yarn + lerna for the first time. Seeing high churn in yarn.lock files across different developers’ machines.

We’re unsure if we should be committing yarn.lock files in each of our packages/ directories, or ignore them as we wouldn’t be shrinkwrapping with npm.

Your Environment

Multiple developer machines, either OS X 10.11/10.12 or Ubuntu

Executable	Version
lerna --version	2.0.0-rc.4
npm --version	3.10.8
yarn --version	0.23.4
node --version	v6.9.1

OS	Version
macOS Sierra	10.12.3

Looking for guidance/recommendation on committing or ignoring yarn.lock files in packages/. While yarn’s guidance on lockfiles is that they should be committed, I’m wondering if the same advice applies when using lerna to manage multiple packages.

We’re in the early stages of setting up a monorepo with lerna for a universal app and most (if not all) dependencies are listed in both the project root (for the web server) and duplicated in each package’s package.json.

Using npm@3 in a monorepo, I would usually use a shrinkwrap to lock down versions in the app and let packages embrace semver. Unfortunately, I’m not sure if or how the switch to yarn changes best practices here.

It’s early on, so I’m tempted to YOLO and learn from our mistakes, but I’m seeing a bunch of churn in yarn.lock files across different developers’ machines–along the lines that I would normally expect with a freshly generated shrinkwrap in npm@2 😢.

I looked around in issues and docs, but I couldn’t find any guidance. Likewise, if there are resources elsewhere that I can use, I’m happy to ask questions elsewhere 😃

If anyone’s able to share what they consider to be best practices working with yarn and lerna (and why), I’d be both grateful and an imminent docs contributor.

Thanks in advance… you’re doing some great work here!

[evocateur]

…[Most] (if not all) dependencies are listed in both the project root […] and duplicated in each package’s package.json.

Have you tried --hoist yet? It sounds like you’re pretty close to the ideal pattern for hoisting already. If everything gets hoisted, no lockfiles will be generated in the packages/* directories, and the root lockfile becomes the single source of truth.

Personally, I do exactly that: yarn.lock in the root, command.bootstrap.hoist = true in lerna.json, and the only thing that happens in packages/* during lerna bootstrap execution is symlinking and running prepublish. (Granted, I’m not using --npm-client=yarn, but same diff in this case)

Unfortunately, there is currently no automated way to “synchronize” hoisted package versions, so whenever you update a version in the root, you’ll have to manually bump the matching package versions under packages/*/package.json (it will warn you of a mismatch during the next lerna bootstrap if you don’t sync). It’s something I’d like to get around to at some point, though given the length of my todo list, it probably won’t get done any time soon…

[lock[bot]]

This thread has been automatically locked because there has not been any recent activity after it was closed. Please open a new issue for related bugs.