Questioning assumptions on lerna vs yarn

Feburary 7th 2018

As I mentioned in my blog post, there are several questions that need answering about our assumptions around lerna and yarn. Times are going to be pretty far apart today as I'm dealing with some work at home today.

14:47 Tested for my assumption that lerna bootstrap was going to be good enough and it turned out that I was correct. Admittedly I didn't do this on a clean repo. I only ran rm -rf node_modules. I'll do a full deletion of the repo and test it on a fresh download.

15:30 Succesfully installed. Now to do it again with yarn install. Technically, newer versions of yarn should be able to resolve workspaces just fine.

15:41 And we have success. Right now, yarn, yarn install, and lerna bootstrap all do the same thing. We could probably get rid of our command yarn && yarn run bootstrap now since that basically expands to yarn install && yarn install && yarn install.

15:53 One thing I could not reproduce all this while working on it was the automatically updating yarn.lock file. This could possibly be because the yarn.lock file was updated 3 days ago. Let's try on another repo.

15:58 Working on analyze repo.

Yey! Attempting to start it up fails. Which means that I need to update dependencies.
Looks like this one had it's yarn.lock file updated as well recently. So no issues there.

End of day reflections

After a lot of testing, it looks like the repos are actually in a good place now that yarn workspaces are in play. No credit to me. All I need to do is propose and submit some Pull Requests that clean up the commands in package.json and pre-build.sh.

February 7th 2018

08:30 Starting with the buffer-publish repo:

This should be interesting. I haven't updated the repo in a while on my laptop. Can I make it work without borking the node_modules list.
Oof. This is going to take some time to pull images. Switching over briefly to my Slack status updater project.

09:09 Done. #SlowInternet.

And as hoped for, it's broken. Now to run my command docker run --rm -v $(pwd):/src -w /src node:8.9.4 yarn install
I would hope that the yarn.lock file does NOT change. And that the app starts up peacefully after that.
Urgh my goodness! Needs to download node:8.9.4 image. Thankfully it looks like the internet is cooperating. But now yarn needs to download the rest of the node based internet. Joking about this is still cool at the time of this writing ok?

Well... Doesn't feel like much of a joke anymore. :(

09:25 Done! Now let's see if that worked.

As the saying goes, Boom, Shake, Shake the room. And the lock file was not updated which means everything worked as intended.

So this is all great news. It means that our development environment has reached a very high level of stability. So it's time to help clean up.

10:30 I spent some time investigating a hunch that I had about the lock file issue.

I suddenly realised that our Docker images being built are on an older branch of Node. The Docker images for this do NOT come with a newer version of yarn. They in fact come with version 0.24. For context, yarn workspaces first dropped in 0.27.
At the same time, we haven't standardized running yarn install from inside a docker container vs using a local installation of yarn. This means that the newest versions of the yarn.lock files were probably generated using a newer version of yarn. From what I know, most of us are running yarn 1.3.2 on our own machines.
Between 0.24 and 1.3.2 versions of yarn it's entirely possible that we've been seeing two different algorithms of yarn.lock file generation.

And when I investigated using an old version of yarn, it turned out that my assumption was correct. It basically wipes the entire yarn.lock file and attempts to rewrite it. Whether it is following the lockfile at all is another question but I don't need to answer it right now either.

And with that, it's time to take a breather for the day. I'll probably do some communication related stuff and come back to this later in the afternoon.

14:00 Took a look at buffer-analyze to see what I can find.

Good news here is that this repo being a slightly newer one is also utilizing a newer version of Node Docker images that comes with yarn 1.x.x.

I feel like at this point, a lot of my questions have been answered. I know what recommendations to make to the team:

Standardizing which version of yarn we are running inside of our Docker containers.
Standardize the method of installation (choosing between a Docker based approach vs a local installation approach).
Cleaning up the package.json files to remove the duplicated work that happens in the steps like yarn init which basically runs yarn install twice over.

So with that I can pause this project :).

Posted on February 07 2018 by Adnan Issadeen