Use resolutions to override a dependency’s dependency version.
This invites breakage, though.
Perhaps most importantly, remember to check if a vulnerability is reported on a dev dependency. If it is, ignore it.
Prompted by this vulnerability report
knex-cleaner specifies a dependency on
lodash@^3.5. The latest, secure lodash is 4.17.11.
yarn upgrade knex-cleaner will find the latest version of the major release specified by
knex-cleaner, which is
firstname.lastname@example.org, which is still vulnerable.
Upgrading knex-cleaner leaves lodash at v 3.10. knex-cleaner requests a version of lodash greater than 3.5.
├─ email@example.com │ ├─ bluebird@^2.9.13 │ ├─ firstname.lastname@example.org │ ├─ lodash@^3.5.0 │ └─ email@example.com
If a greater than package is requested w/
^, does it lock it to that version number? So the highest v 3 package?
So is it possible to change a dependency’s dependency version?
--latest flag looks promising
Nope =/ It only ignores the caret range if a package w/ the
latest tag exists.
Exactly what I need. A way to override the semver of a package’s dependency.
Back to 0 vulnerabilities =D <- Wrong =( knex-cleaner used a lodash method that was deprecated in lodash 4.0 causing it to break. The options at this point are to
- Replace knex-cleaner
- Accept and document the vulnerability
- Realize that knex-cleaner is a dev dependency and doesn’t need to be vulnerable free
And the most important lesson of all…
knex-cleaner is a dev dependency. Meaning that vulnerabilities in it don’t matter. :grimace: