Yarn: Procedure for redeploying JavaScript dependencies to Production Server (usage of `yarn.lock` file)

Viewed 273

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:

  1. Updating the 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)
  2. For keeping my lock file in sync with other developers to ensure that they are developing/testing from the exact same dependency versions, and
  3. For updating/re-synching the 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.

2 Answers

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.

  1. Honestly, this is a matter of opinion/preference. I have seen a few strategies:

    • Using yarn upgrade
    • Manually bumping the version in package.json before running yarn
  2. Like Fabien mentioned: use yarn check

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

    • Builds are faster because you don't have to fetch packages from the npm registry.
    • Your builds will fail if you do not have the right dependencies.
Related