Our MarkBind library dependencies are slowly getting outdated over time. Some of them are in need of upgrading due to the warnings that npm shows (warnings include the use of deprecated features in libraries).
The worst case scenario of the upgrade outcome, would be that some of major features might get broken during the upgrade (we already spot one before, by accident, in #413). However, we now have a tried-and-tested version of MarkBind (v1.14.0) that we can fallback on for the worst case scenario, so we can afford to spend as much time as necessary fixing the broken features.
Hopefully if the broken features aren't too difficult to fix, we can try to do all the fixes within the 6 weeks with 1-2 people.
So I think we can afford to give it a go at this juncture.
npm audit (avaliable from npm >= 6.0.0) on master at cfbffbadb4071e297d72c0208b2710b2ff3ad961 (v1.20.0) returns 434 vulnerabilities in our dependencies:
found 434 vulnerabilities (211 low, 205 moderate, 18 high) in 22845 scanned packages
run `npm audit fix` to fix 420 of them.
14 vulnerabilities require semver-major dependency updates.
After some analysis, these are the packages (or whose dependencies) are marked vulnerable at their current versions, categoried by their function in MarkBind:
chokidar: current 1.6.1, latest 2.1.2live-server: current 1.2.0, latest 1.2.1gh-pages: current 1.1.0, latest 2.0.1nunjucks: current 3.0.0, latest 3.2.0markdown-it-table-of-contents: current 0.3.2, latest 0.4.3eslint: current 4.16.0, latest 5.15.1jest: current 22.4.3, latest 24.5.0lodash: current 4.17.5, latest 4.17.11I think we can have PRs to handle upgrades for each of the categories, and ensure that upgrading doesn't break anything? It's not a good look for V2 when potential new authors attempt to install MarkBind and have a scary message about >400 vulnerabilities 馃槗
EDIT: after discussion, we agreed that we should have one large PR to do all the upgrades to reduce package-lock.json churn. Some experimentation suggests that everything should work, with the only large-ish change being in eslint configuration as the eslint config packages need to be updated along with eslint due to syntax changes.
I think we can have PRs to handle upgrades for each of the categories, and ensure that upgrading doesn't break anything? It's not a good look for V2 when potential new authors attempt to install MarkBind and have a scary message about >400 vulnerabilities
Yes let's do that :+1:
Update
Currently vue-strap has a huge magnitude of vulnerabilities that cannot be easily fixed due to breaking changes in packages. Just running npm audit fix breaks the build code.
After running npm install |
--- |
|
After running npm audit fix |
--- |
|
So this issue is blocked until we fully migrate over to Bootstrap-Vue in #814.
On the bright side 馃尀 , Bootstrap-Vue is in active development and have minimal vulnerabilities.
@ang-zeyu Has this been tackled on the vue-strap side of things via https://github.com/MarkBind/vue-strap/pull/130?
yup more or less
Most helpful comment
npm audit(avaliable fromnpm >= 6.0.0) onmasterat cfbffbadb4071e297d72c0208b2710b2ff3ad961 (v1.20.0) returns 434 vulnerabilities in our dependencies:Full results here.
After some analysis, these are the packages (or whose dependencies) are marked vulnerable at their current versions, categoried by their function in MarkBind:
chokidar: current 1.6.1, latest 2.1.2live-server: current 1.2.0, latest 1.2.1gh-pages: current 1.1.0, latest 2.0.1nunjucks: current 3.0.0, latest 3.2.0markdown-it-table-of-contents: current 0.3.2, latest 0.4.3eslint: current 4.16.0, latest 5.15.1jest: current 22.4.3, latest 24.5.0lodash: current 4.17.5, latest 4.17.11I think we can have PRs to handle upgrades for each of the categories, and ensure that upgrading doesn't break anything?It's not a good look for V2 when potential new authors attempt to install MarkBind and have a scary message about >400 vulnerabilities 馃槗EDIT: after discussion, we agreed that we should have one large PR to do all the upgrades to reduce
package-lock.jsonchurn. Some experimentation suggests that everything should work, with the only large-ish change being ineslintconfiguration as theeslintconfig packages need to be updated along witheslintdue to syntax changes.