The JS build system ecosystem could definitely use some help along the whole "reasonable tools I can expect to work together well" front. I swear, 30% of my time is spent fighting the build systems and their plugins that hate each other.
EDIT: to add, I think the TS team has done such a bangup job on Typescript that I would love it if they could create a build system as well. Some things that would be nice to have:
* Build-time loading of static resources (.json into js objects, html into strings, etc.)
* File watching and processing for more than just .ts/.js files
* Optimization. Not just tree-shaking and minification, but you could actually get a little more advanced due to the static types and ES6 modules.
* Environment-dependent compilation (compile these files in this way, inserting these static values where ENV variables are used in the source, etc.)
* Target capabilities analysis (ie. for this set of browsers and versions, what is the Lowest Common Denominator for browser capabilities, and ergo, what babel transforms and browser shims should be included?)
* Integrated contracts testing with test elision (ie. run these tests in these (karma? selenium?) environments and if failing, throw a compilation error or warning, and if passing, strip the tests from the compiled source).
* Source packaging (gzipping, etc.), and deployment plugins (ie. deploy compiled assets to S3, package for NPM, etc.).
All of these are pain points in Typescript projects, and all of them touch TS projects in such a way that it makes it even more painful in existing build systems.
I find webpack to be quite a 'holistic' solution I got pretty much everything out of the box or with minimal googling.
I agree though over-fragmentation is a huge problem for JS, we need the big players (either foundations or companies) to put their weight behind one or two solutions and just get on with it :-)
Google sort of already has one, and has for a long time.
Now that their Closure Compiler supports ES6 quite well, I've had a decent amount of success writing my app using straightforward ES6 and referencing the extensive Closure Library for functionality I would've previously pulled in npm packages for.
And the nice thing is that the whole library is written in such a way that all of the compiler's advanced optimizations and branch pruning, and dead code elimination work nicely on it so your compiled JS ends up containing only the code you need, and none of the code your don't need. If you want to use JSX in React projects, you can still zip the code through Babel or Typescript before feeding it to Closure.
It certainly won't work for every project, but it's one way to write modern JS without having to deal with the node/npm ecosystem too much...at least until things settle down a bit.
EDIT: to add, I think the TS team has done such a bangup job on Typescript that I would love it if they could create a build system as well. Some things that would be nice to have:
* Build-time loading of static resources (.json into js objects, html into strings, etc.)
* File watching and processing for more than just .ts/.js files
* Optimization. Not just tree-shaking and minification, but you could actually get a little more advanced due to the static types and ES6 modules.
* Environment-dependent compilation (compile these files in this way, inserting these static values where ENV variables are used in the source, etc.)
* Target capabilities analysis (ie. for this set of browsers and versions, what is the Lowest Common Denominator for browser capabilities, and ergo, what babel transforms and browser shims should be included?)
* Integrated contracts testing with test elision (ie. run these tests in these (karma? selenium?) environments and if failing, throw a compilation error or warning, and if passing, strip the tests from the compiled source).
* Source packaging (gzipping, etc.), and deployment plugins (ie. deploy compiled assets to S3, package for NPM, etc.).
All of these are pain points in Typescript projects, and all of them touch TS projects in such a way that it makes it even more painful in existing build systems.