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.
To acknowledge
yarn checkerrors, you need to use thepackage.json > resolutionsmap.
The resolutions key allows you to manually specify that you meant to override the dependent of a dependency, for example:
"resolutions": {
"@vue/cli-plugin-unit-jest/jest": "^24.6.0",
"@vue/cli-plugin-unit-jest/babel-jest": "^24.6.0",
},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!
The lessons: yarn check is a great way to keep node_modules in sync. Use the package.json > resolutions field to acknowledge dependency errors as warnings.
