News for hackers. Stuff that matters.
Re:Case Study: Npm uses Rust for its CPU-bound bottlenecks [... by ddebernardy on Sunday March 03, 2019 @02:58PM (#19296452)
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.

Re:Case Study: Npm uses Rust for its CPU-bound bottlenecks [... by acdha on Sunday March 03, 2019 @03:35PM (#19296677)
That’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.
Re:Case Study: Npm uses Rust for its CPU-bound bottlenecks [... by steveklabnik on Sunday March 03, 2019 @03:58PM (#19296817)
npm now automatically reports known vulnerable packages, right?
Re:Case Study: Npm uses Rust for its CPU-bound bottlenecks [... by acdha on Sunday March 03, 2019 @04:28PM (#19297026)
Yes - 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.
Re:Case Study: Npm uses Rust for its CPU-bound bottlenecks [... by acdha on Sunday March 03, 2019 @07:11PM (#19297814)
Oh, 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.