Yeah, the size of my node_modules directory doesn't bother me that much. I've worked on some large Node projects in the past, and didn't care too much about how many modules I had installed because I wasn't exactly running out of disk space.
It only really bothered me in an aesthetic sense; although everything worked fine, it just felt messier than necessary. The huge JS bundles we're sending to the browser after running Webpack or Browserify bother me a lot more. Since we're using npm for pulling in front end dependencies, and CommonJS modules aren't statically analyzable, tools like the Closure Compiler and Rollup can't perform a lot of their advanced optimization and tree shaking. We'll get to a better place soon enough, though.
Yeah, the migration to ES6-style modules, Webpack2 etc will help a lot. There's still some bits to work out... about ready to do a new version of a few module in NPM and just declare that said module need to be used with babel+es6, async functions and decorator transforms... I'm tired of waiting, and it'll make the modules themselves cleaner not having to transform before publishing to npm in the end.
It's funny that a lot of this stuff is finally making it into the browsers and platform, when I've been using it for almost 2 years now. Looks like async is going in behind a flag in node 7.
It only really bothered me in an aesthetic sense; although everything worked fine, it just felt messier than necessary. The huge JS bundles we're sending to the browser after running Webpack or Browserify bother me a lot more. Since we're using npm for pulling in front end dependencies, and CommonJS modules aren't statically analyzable, tools like the Closure Compiler and Rollup can't perform a lot of their advanced optimization and tree shaking. We'll get to a better place soon enough, though.