Managing Yarn Dependencies

There are a couple of ways that you can update a dependency in yarn. But perhaps at the most basic, there are two main ways you can update dependencies: in bulk, or individually. Before you do any updating of dependencies, though, ensure you do not have a build currently running or it will not be able to update.

Updating a Single Dependency

There are two main ways to update a single dependency: through the command line or through package.json.

Perhaps the most simple way to update a dependency is simply to navigate to the package.json file. Every app has two package.json files, one in the root of the app for general dependencies, and one in the client folder for Ember dependencies. Typically, you will use the client one much more often so it will need more updating.

Once you have navigated to package.json, you simply need to find that app’s name in package.json under devDependencies and update the version string. For information about the syntax of version strings, check out NPM docs About Semantic Versioning, but to summarize the salient points of this article, for consistency purposes in Informatics, a version with a carat will allow minor and patch releases (^1.0.0 will allow 1.0.1 or 1.1.0, but not 2.0.0), a tilde will allow only patch releases (ie ~1.0.0 will allow 1.0.1, but not 1.1.0 or 2.0.0), and nothing before the number will only accept that exact version (however this is not advisable unless the next patch update introduces breaking changes). We never accept major releases automatically.

Alternatively, the second way to update a single dependency is through the command line. you can also upgrade a single dependency by running the command yarn upgrade <package> --latest where <package> is the name of the dependency you wish to update (for example, yarn upgrade @bennerinformatics/ember-fw --latest). This will install the latest version of a package and update your package.json file automatically.

Updating all dependencies

To upgrade all dependencies for an app, the easiest way is using the command yarn upgrade-interactive --latest. This will open up a UI allowing you to select which packages to update from a list as shown below

Following the instructions displayed, you can enter “a” then press enter to update all dependencies, or use the arrows and space to select packages individually. After running this command, it is normally a good idea to delete the file yarn.lock then to run the command yarn again to ensure dependencies of dependencies are properly updated.

Note: At our current state, you should never just type "a" and press enter, as there are many blacklist dependencies that you need to avoid updating. What is better to do is to pull up the dependency blacklist, and use the arrows and space bar to select all the dependencies except for the blacklisted ones.

Alternatively, running yarn upgrade or deleting the yarn.lock file will update all the dependencies that are not matching up with your restraints, but it will not go beyond the restraints in your package.json file (for example if ember-source has released version 3.10.3 or 3.11.0, and you are on 3.10.2, but your constraint is ~3.10.0, then using this update message will move you to 3.10.3 since you have told it that works)

Testing and committing package updates

After updating dependencies, it is always a good idea to try building your app to ensure everything works fine. If it does not, you can easily rollback package.json and yarn.lock to an older version using git and attempt to find which package broke.

If it does work, it is a good idea to commit your changes to ensure other developers have the latest versions of the packages. Simply commit changes to both package.json and to yarn.lock.

There are times in which your code will build, but the changes you know should be there are not (ie the head developer says XYZ should happen when you update ember-fw to the latest version, and these things don't happen for you). In these cases, you should check your yarn.lock file to ensure that there are not two versions listed of the required dependency. If there are two instances of the dependency, yarn will use the lowest version, not the highest. Take for example the following lock file:

"@bennerinformatics/ember-fw@^2.0.25":
  version "2.0.25"
  resolved "https://registry.yarnpkg.com/@bennerinformatics/ember-fw/-/ember-fw-2.0.25.tgz#eb261cda55cb1c72133bc50631be8e9056d39135"
  integrity sha512-Tl4cRtR30Xxbves2VocQVfAY8eawr2mTf9v5c5v9IaPboyqaaT6hpbSLrqrPi0fqO8v2liDdsil9Ryew49PNNg==
  dependencies:
   ... [lists dependencies]

"@bennerinformatics/ember-fw@^2.0.22":
  version "2.0.22"
  resolved "https://registry.yarnpkg.com/@bennerinformatics/ember-fw/-/ember-fw-2.0.22.tgz#55e94b39c4414b6b6bc69fd0a1cf5695aa5f42b3"
  integrity sha512-GDtcUO4jyu45jUJUXNKeaRnJiVF0sCZdil3QLbFAELulmgByVKMO8tEWffA4HHtOiRoe0nkhJpSJLXBRYFRkJg==
  dependencies:
    ... [lists dependencies] ...

In this lock file, while the most recent version of ember-fw is 2.0.25, because the oldest version is 2.0.22, it will not be on 2.0.25. The best way to fix this is to delete the yarn.lock file and run yarn again, but this will update all the yarn packages. So if you run into errors after updating all your packages, a grey-tape solution is to minorly editing the yarn.lock file to have both the lower and higher version, separated by a comma resolving to the higher version. In our example it would be like so:

""@bennerinformatics/ember-fw@^2.0.22", @bennerinformatics/ember-fw@^2.0.25":
  version "2.0.25"
  resolved "https://registry.yarnpkg.com/@bennerinformatics/ember-fw/-/ember-fw-2.0.25.tgz#eb261cda55cb1c72133bc50631be8e9056d39135"
  integrity sha512-Tl4cRtR30Xxbves2VocQVfAY8eawr2mTf9v5c5v9IaPboyqaaT6hpbSLrqrPi0fqO8v2liDdsil9Ryew49PNNg==
  dependencies:
   ... [lists dependencies]

{Delete the older version resolution}

Note: Editing the yarn.lock file should be a LAST RESORT, and only be done if there is no other solution to fixing it. Ordinarily you should not be editing this file.

Dependency Blacklist and Greylist

It is important to keep a running total of the dependencies that introduce breaking changes into our code for our apps, so whenever you have dependency issues, make sure to check the Yarn Dependency Blacklist, which are the dependencies that cannot go any higher without breaking our code, and Yarn Dependency Greylist, which introduce bugs, but also have known work arounds. Whenever you encounter a dependency issue, make sure to add it to the appropriate list as well.