Can we commit / track package-lock.json?

[dellagustin]

Hello @daveajones ,

Can we commit package-lock.json? Without it the build is a bit flaky and can break when new versions of the dependencies are released, even when there is no code change in the project itself.

[dellagustin]

I think I just had one of those issues. npm run dev started failing due to missing module dotenv-webpack after I deleted package-lock.json and the node_modules and run npm install for a fresh start.
This module is not on package.json and this file was only changed the last time 6 months ago.
I can only imagine this was due to some transient dependency that changed over time because package-lock.json.

[stevencrader]

We have been using yarn for this project so there is a yarn.lock file already committed. You usually don't want both lock file types.

[dellagustin]

hmmm ok, that does make sense.
I don't know how I did not see that... well I guess I have been stuck to npm for too long 😄 .

[dellagustin]

Follow up question, I installed yarn and typed yarn just to test if it was working, it triggered something that looks like an install process.
As result, the file .yarnrc.yml and folder .yarn/cache (with a bunch of zip files) were created.
I'm assuming that .yarn/cache has to go onto .gitignore, but how about .yarnrc.yml?

[stevencrader]

Did you install yarn local or global? I don't see those in my folder when yarn is installed globally. Regardless, I don't see any issue adding them to the ignore file. I don't see any reason we would want to track that information.

[stevencrader]

What version of yarn are you running? I'm running 1.22.15 on Windows.

[dellagustin]

@stevencrader it is installed globally. I recently installed it.
yarn --version spits out 3.4.1.
The content of .yarnrc.yml is simply:

nodeLinker: node-modules

https://yarnpkg.com/configuration/yarnrc#nodeLinker
Maybe this is only required for newer versions?

As for committing .yarn/cache, I did some quick research.
It depends on whether we want to follow the Zero-install philosophy (essentially not needing to run yarn install after cloning, plus this is supposed to give you more stable builds in comparison to having to run yarn install). The drawback would be that it makes the tracked source code heavier.

By default we are not following this philosophy, so I would follow the guidance from yarn's Q&A with respect to the .gitignore and introduce the following:

.pnp.*
.yarn/*
!.yarn/patches
!.yarn/plugins
!.yarn/releases
!.yarn/sdks
!.yarn/versions

[dellagustin]

So, all sorted out, we don't commit package-lock.json as we are using yarn and not npm.
#230 addressed the files that need to be ignored and also the config files.