I've read the documentation on Yarn, and I know the lock
file is supposed to be committed to VC. See this and which explains at a high-level why the lock file is necessary, and this which lists a bunch of commands without much explanation of what they actually do!
I've also read a lot of questions on StackOverflow which asks about whether the lock
file should be committed to VC.
However, all the documentation and SO threads seems to overlook the detail that I want to know, which is the following; What is the correct procedure (the correct bunch of commands to run) for:
yarn.lock
file when I need to (i.e. in the development environment where I want to pull the latest minor versions and update the lock
file to reflect this)node_modules
directory on the production server (i.e. to ensure that the production server isn't running on a different/breaking version of dependent packages)I ask partly because in the past while doing a git pull
on the server, I've faced messages telling me that the yarn.lock
file has been updated independently of the development/VC process. As far as I'm concerned, this should never be allowed to happen.
The yarn. lock file is automatically generated/updated when you install package(s). To my knowledge anyway. Exactly right.. just run yarn install (or even just yarn as it will default to install..) and it'll create the lockfile if it doesn't already exist.
If you remove the lock file completely and then run yarn install , yarn will re-resolve all versions to the latest allowed by their specified ranges, and thus fix all those duplicated deps.
The yarn-lock file is in the repo. If Compared to composer for php, I would expect that when I run yarn install , that the dependencies are installed based on the lock-file, and the lock file does not change. With composer install for php, you install always the same version for each package on any environment.
the following information are based on what we use daily at Orange, this may be not the single truth.
1 ) Updating yarn.lock
yarn upgrade [package | package@tag | package@version | @scope/]... [--ignore-engines] [--pattern]
This command updates dependencies to their latest version based on the version range specified in the package.json
file. The yarn.lock
file will be recreated as well.
source : https://yarnpkg.com/en/docs/cli/upgrade
2) Dependency between developers
What i suggest you to do is to create a script that will check the current 'recomended' version to have with the help of:
yarn check
Verifies that versions of the package dependencies in the current project’s package.json
match those in yarn’s lock file.
source : https://yarnpkg.com/en/docs/cli/check
3) Updating server production
The same as 2 ) using a git hook script, should help you to yarn check
if the package.json
version are correct if not launch a yarn update
.
Honestly, this is a matter of opinion/preference. I have seen a few strategies:
yarn upgrade
package.json
before running yarn
Like Fabien mentioned: use yarn check
You can use yarn offline mirrors where you commit caches of your npm packages into version control. (See this medium article)
Plus there are lots of upsides when using yarn --offline
:
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With