Markbind: Upgrade MarkBind and vue-strap library dependencies

Created on 21 Nov 2018  路  5Comments  路  Source: MarkBind/markbind

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.

a-DevOps p.Medium

Most helpful comment

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.

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:

  • Live preview

    • chokidar: current 1.6.1, latest 2.1.2

    • live-server: current 1.2.0, latest 1.2.1

  • GitHub Pages deployment

    • gh-pages: current 1.1.0, latest 2.0.1

  • Building pages

    • nunjucks: current 3.0.0, latest 3.2.0

    • markdown-it-table-of-contents: current 0.3.2, latest 0.4.3

  • Development tools

    • eslint: current 4.16.0, latest 5.15.1

    • jest: current 22.4.3, latest 24.5.0

    • lodash: current 4.17.5, latest 4.17.11

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 馃槗

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.

All 5 comments

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.

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:

  • Live preview

    • chokidar: current 1.6.1, latest 2.1.2

    • live-server: current 1.2.0, latest 1.2.1

  • GitHub Pages deployment

    • gh-pages: current 1.1.0, latest 2.0.1

  • Building pages

    • nunjucks: current 3.0.0, latest 3.2.0

    • markdown-it-table-of-contents: current 0.3.2, latest 0.4.3

  • Development tools

    • eslint: current 4.16.0, latest 5.15.1

    • jest: current 22.4.3, latest 24.5.0

    • lodash: current 4.17.5, latest 4.17.11

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 馃槗

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 |
--- |
before-audit|

After running npm audit fix |
--- |
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

Was this page helpful?
0 / 5 - 0 ratings