Acknowledging Yarn Check Errors
Using the resolutions field to ignore yarn check errors when you know they’re safe.
Yesterday I was locking down our development and build chain. And while everyone knows you have to lint and test, I’ve only just recently discovered
yarn check. A command that allows you to make sure that the node dependencies you’re working with locally are in sync with the repo.
As a command
yarn check is fairly easy to use. By default it checks that your
yarn.lock matches the ranges resolved from
package.json, and that the versions of the npm packages you’ve got installed locally match those hashed in your
yarn.lock file. If it passes without errors, then your local environment is the same as everyone (including the build machine) else’s!
A challenge, however, is that often you need to ignore warnings. Especially when you’ve insisted on a later version of a package that another depends on. In our case, we we’re using a version of jest beyond that which vue-cli specified. We had tested this setup, but
yarn check (correctly!) threw errors letting us know that our
package.json resulted in something which could not be properly resolved.
yarn checkerrors, you need to use the
package.json > resolutionsmap.
The resolutions key allows you to manually specify that you meant to override the dependent of a dependency, for example:
Where these entries take the form
"dependency/dependencies-dependency/etc...": "version you want".
After you’ve specified the resolution,
yarn check will acknowledge the error as a warning (after all, you are working against the semver). But it means you’ll be back to an error code of zero; to the delight of your build machine!
yarn check is a great way to keep
node_modules in sync. Use the
package.json > resolutions field to acknowledge dependency errors as warnings.