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
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 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.lockfile 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
February 7th 2018
08:30 Starting with the
- This should be interesting. I haven't updated the repo in a while on my laptop. Can I make it work without borking the
- 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.lockfile does NOT change. And that the app starts up peacefully after that.
- Urgh my goodness! Needs to download
node:8.9.4image. Thankfully it looks like the internet is cooperating. But now
yarnneeds to download the rest of the
nodebased 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
lockfile 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,
yarnworkspaces first dropped in
- At the same time, we haven't standardized running
yarn installfrom inside a
dockercontainer vs using a local installation of
yarn. This means that the newest versions of the
yarn.lockfiles were probably generated using a newer version of
yarn. From what I know, most of us are running
yarn 1.3.2on our own machines.
yarnit's entirely possible that we've been seeing two different algorithms of
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
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
yarnwe 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.jsonfiles to remove the duplicated work that happens in the steps like
yarn initwhich basically runs
yarn installtwice over.
So with that I can pause this project :).
Posted on February 07 2018 by Adnan Issadeen