Upgrading javascript package’s deep dependencies using yarn.

To upgrade a package in your package.json file, say your package isjsdom. You execute the following command:

yarn upgrade jsdom

Dependency tree for jsdom

But what if you want to upgrade any indirect or deep dependencies of your package, say you want to upgrade the acorn-globals package.

Running yarn upgrade acorn-globals will have no effect on either package.json or your yarn.lock file.

Why?

yarn upgrade only upgrades the packages listed under package.json and not the indirect or deep dependencies.

So how do we upgrade then?

CASE 1
A package which has only one version in yarn.lock

1. Open yarn.lock and find the section which has the package’s version, resolved, integrity, etc.
2. Delete the section for the package, in our example acorn-globals
3. Run yarn

After deleting the section for the package to be upgraded(left), and After running yarn (right)

Our package has now upgraded to the latest version.

[ Note: This will only upgrade to the latest minor/patch version. ]

Case 2
A package which has multiple versions in yarn.lock.

Say you wanted to upgrade acorn package instead. As you can see it has multiple versions.

acorn has two versions here.

1. Open yarn.lock and find the section which has the package’s version, resolved, integrity, etc.
2. Delete the all the sections for the package, in our example acorn
3. Run yarn

After deleting all the sections for the package acorn(left), and after running yarn(right)

This will upgrade the package version in each section to the latest minor/patch version.

Okay, But how can I upgrade all the sections to the latest version?

This is a bit tricky/experimental, and the process involves upgrading the packages in the dependency chain one by one following the steps mentioned above.

To find the dependency chain run =>yarn why acorn

This will give you the dependency chain.

For acorn@5 we have the chain as:
jest#jest-cli#jest-config#jest-environment-jsdom#jsdom#acorn

Now we need to start upgrading the packages from right to the left following the steps mentioned above unless the package dependency upgrades to the lastest.

Please test your application thoroughly as the dependencies are updated.

Note: The dependent packages are not immediately updated as soon as a new package is published. So after a point, you have to either wait for the developer to update the package or raise a pull request to move things faster.

FAQ

What if I delete and rebuild the yarn.lock file, this upgrades my packages too?
Never do this. This will lead to the catastrophic failure of your application. This upgrades all the packages to the latest versions which might have breaking changes and your application stops working.

I don’t use yarn.lock, I never faced any issues, do I really need this?
Yes you need the yarn.lock if you use yarn, each time you are running the command yarn install you are installing the latest packages of each dependency, this will also lead to application failure.
Your application is tested for a particular version of a package. Say the latest version of a package was buggy and your application has installed it, without yarn.lock you will always install the latest available.

Can I use the same process for Github's Security Alerts?

Yes, the process for fixing these security alerts is the same as mentioned above.

This also involves upgrading the indirect dependencies. Sometimes, if you are lucky, Github's dependabot creates a Pull Request for you, doing the same thing.

Is the process safe?
Yes, say if you were installing that main package jsdom for the first time, the latest of the deep dependent package acorn would have been installed.

Why Can’t I directly upgrade the top-level package in the dependency chainjest#jest-cli#jest-config#jest-environment-jsdom#jsdom#acorn ?
The answer is that you can, but you shouldn’t ideally unless you are ready to upgrade the main package. Say you were on jest@20.x.x and the latest is jest@25.x.x, jumping 5 major versions up generally brings up breaking API changes, so unless you haven’t planned to upgrade the package you should stick to upgrading the deep dependency if that was the aim.