Outdated dependency security vulnerability about escodegen

[michaelficarra]

Published version 2.1.0.

[ericcornelissen]

Note that at v2.0.0 this was still a regular dependency but on master (7a48a21) it's actually both a development dependency instead and at ^0.9.1. So, assuming master is stable, resolving this would be as easy as deploying the development head.

[wellwelwel]

@invaderb the fact that ^0.9.1 is used in package.json means v0.9.1 or a higher patch version can be installed by users of escodegen - in this case both v0.9.2 and v0.9.3, the latter of which resolves the vulnerable dependency. So, it would resolve the problem for any users of the latest version of escodegen, even if they still have to manually update the transitive dependency on their end.

The first comment on the issue you linked points this principle out as well.

@ericcornelissen, it would be great if this repository was synced with npm.

[wellwelwel]

This should be fixed automatically by:

escodegen/package.json

Line 51 in 7a48a21

"optionator": "^0.9.1",

Especially since it's a development dependency at master branch

But this repository isn't synchronized with npm package, where it's still as "optionator": "^0.8.1".

---

@estools, @Constellation and @michaelficarra, please can you check it?

[invaderb]

@ericcornelissen 0.9.1 still has the vulnerability in it, and 0.9.2 had some sort of hiccup and a newer version was published to npm talked about in this thread here on eslint
eslint/eslint#17317

[ericcornelissen]

@invaderb the fact that ^0.9.1 is used in package.json means v0.9.1 or a higher patch version can be installed by users of escodegen - in this case both v0.9.2 and v0.9.3, the latter of which resolves the vulnerable dependency. So, it would resolve the problem for any users of the latest version of escodegen, even if they still have to manually update the transitive dependency on their end.

The first comment on the issue you linked points this principle out as well.