4 ms·
Anecdotal, but I recently used Gulp in a project to run some css clean-up tasks as part of a build process. The JS dependencies: "gulp" "gulp-clean-cs
by ddebernardy 8y ago
Anecdotal, but I recently used Gulp in a project to run some css clean-up tasks as part of a build process.
The JS dependencies:
"gulp"
"gulp-clean-css"
"gulp-postcss"
"gulp-uglify"
"autoprefixer"
"postcss-uncss"
"uncss"
The number of node modules: just over 400.
So I'm not at all surprised that this might create surprises when deploying JS services in production.
- acdha 8y agoThat’s an ongoing annoyance with using NPM in a security-conscious environment. It’s really easy to end up with thousands of submodules and the amount of time you’ll have an audit showing a vulnerable package can be many months while layers of dependencies slowly update. You can usually show that it’s not exploitable but the number of modules on the average project means you’ll be doing that all the time.
- steveklabnik 8y agonpm now automatically reports known vulnerable packages, right?
- acdha 8y agoYes - which is great for surfacing this, along with GitHub’s alerts, but unless it’s a direct dependency I find I’m usually just stuck researching the vector and waiting months for numerous layers of dependencies to update in sequence.
- acdha 8y agoOh, and to be clear: I think this is a problem with OSS sustainability – shipping updates takes real work – more than NPM, mildly exacerbated by the JS stdlib leading to more modules being used instead.