Currently we have Babel parsing the ES6 imports. Webpack 2 now can handle this and potentially simplify our Babel configuration and improve bundling performance.
All it took to let webpack handle ES6 imports was excluding the babel module that handles them.
Unfortunately, there is no support for determining if such imports are themselves ES6 code and so we still needed that awful regex to tell Babel which to transpile. I've replaced that with a function closer to what we actually mean, but we're somewhat going against convention by not pre-transpiling our npms.
Hopefully a standard for that emerges as I prefer to keep the stripes modules free of the extra tooling.
There are jsnext:main and pkg.module to designate main files for ES6. However, those too are just about module loading and don't imply these need to be transpiled. Presumably because projects vary in their code standards and each have their own babel config. But truly making use of things like babel-preset-env to target code to supported browsers could motivate a move to not-transpiling-all-the-way.
Currently we have Babel parsing the ES6 imports. Webpack 2 now can handle this and potentially simplify our Babel configuration and improve bundling performance.
https://webpack.js.org/guides/migrating/#mixing-es2015-with-amd-and-commonjs
It may also help make the bundle smaller via tree-shaking though apparently this effect is less than you might expect: https://advancedweb.hu/2017/02/07/treeshaking/