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

[jvivs]

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...

[jvivs]

Ah, good to know!

Y'know we haven't tried --hoist yet. It sounded like a nice solution for speeding up install time by reducing duplication of common dependencies, but ran into errors when testing out --hoist with local unpublished packages (#501).

We're still pretty early and I was hoping that specific bug should go away once we've started publishing... but now that I think about it, I guess it would crop up every time a new package is created.

I guess it's time to dig into the issue a bit more.

I'll see what I find and come back w/ a bug report and/or PR.

[kraenhansen]

@jvivs Have you guys made progress? I am wondering the same.
If you're still going at this, the thread on introducing yarn in lerna has some interesting insights: #371
@seansfkelley published https://github.com/palantir/yerna which seems to tackle some of the issues that stems from a yarn+lerna environment.

[seansfkelley]

FWIW, I always commit my lockfiles. The mild inconvenience of having to have approximately the same yarn version across devs' machines is far outweighed by never having to worry about an entire class of bugs. Said inconvenience really amounts to "oops, my lockfile changed, guess it's time to update yarn again" at worst.

[evocateur]

Ultimately, the choice to version lockfiles is up to the project. Lerna will work either way.

[lock]

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.