codethrasher

December 16, 2020  ·  Programming Yarn Npm

Yarn-NPM

package.json

resolutions field

yarn specific

Allows you to force the use of a particular version for a nested dependency. e.g.:

1
2
3
4

"devDependencies": {
  "@angular/cli": "1.0.3",
  "typescript": "2.3.2"
}

yarn.lock will contain:

1
2
3
4
5
6
7

"typescript@>=2.0.0 <2.3.0":
  version "2.2.2"
  resolved "https://registry.yarnpkg.com/typescript/-/typescript-2.2.2.tgz#606022508479b55ffa368b58fee963a03dfd7b0c"

typescript@2.3.2:
  version "2.3.2"
  resolved "https://registry.yarnpkg.com/typescript/-/typescript-2.3.2.tgz#f0f045e196f69a72f06b25fd3bd39d01c3ce9984"

and within node_modules you’d see:

  • typescript@2.3.2 in node_modules/typescript
  • typescript@2.2.2 in node_modules/@angular/cli/node_modules.

Because TS@2.2.2 is nested within @angular/cli it is impossilbe to force the use of TS@2.3.2 across the entire project (see flattening, for a counter to this).

With the resolutions field yarn will will use the resolved version if a different version is found in a nested dependency.

See this this RFC for details.

It is common to see warnings spewed out into the terminal during a yarn install this is because:

The devDependencies, optionalDependencies and dependencies fields always take precedence over the resolutions field: if the user defines explicitly a dependency there, it means that he wants that version, even if it’s specified with a non-exact specification. So the resolutions field only applies to nested-dependencies. Nevertheless, in case of incompatibility between the specification of a non-nested dependency version and a resolution, a warning is issued.

upgrading dependencies

yarn has a command (yarn upgrade) which upgrades a dependency with yarn upgrade [package]@[version], but annoyingly this doesn’t help in the case of devDepenencies. If you do this with a package that currently sits in the dev category it will add it to the dependencies category and not touch the dev addition.

Instead, do yarn add -D [package]@[version] which will behave as you’d expect upgrade to.

yarn.lock

The yarn lockfile allows an application to freeze a dependency in time so that on various machines (once installed) an application will always have the same dependency version installed.

  1. If a yarn.lock (the lockfile) is not present on yarn install (or, simply, yarn) a new lockfile will be created with the latest dependencies installed

  2. If a yarn.lock is present on yarn install and there are dependencies listed in package.json that don’t exist in the lockfile, yarn will try to update every dependency to the latest

  3. If a yarn.lock is present and all the dependencies in the package.json file are listed in the lockfile, the install will note upgrade any dependency

To prevent the updating of any dependency in a lockfile use --frozen-lockfile when installing (yarn install)

yarn.lock merge conflicts

git rebase origin/master

When the first conflict arises, I checkout the yarn.lock then re-perform the installation

git checkout origin/master -- yarn.lock
yarn install

This generates a new yarn.lock based on the origin/master version of yarn.lock, but including the changes I made to my package.json. Then it’s just a matter of:

git add yarn.lock
git rebase --continue
← Cipher Colocation →