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 lodash@3.10, which is still vulnerable.

The Process

Is this already fixed?

Upgrading knex-cleaner leaves lodash at v 3.10. knex-cleaner requests a version of lodash greater than 3.5.

├─ knex-cleaner@1.1.4
│  ├─ bluebird@^2.9.13
│  ├─ bluebird@2.11.0
│  ├─ lodash@^3.5.0
│  └─ lodash@3.10.1

If a greater than package is requested w/ ^, does it lock it to that version number? So the highest v 3 package?

Yes. That is what it means.

So is it possible to change a dependency’s dependency version?

The --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

  1. Replace knex-cleaner
  2. Accept and document the vulnerability
  3. 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: