Stand up for the jsnext/esnext standard

As the environment evolves we developers often have the need to transpile dependencies into our own configured environments.
Until now most of webpack+babel configuration simply dodged the ball with a node_modules exclusion while transpiling but as we move on this is not going to be the case anymore.

Babel already made huge steps forward on this with the babel-preset-env but lots of these efforts in optimizing the application vanish because most of packages specify:

  • main: transpiled (fully polyfilled) entrypoint
  • module: transpiled (fully polyfilled) es6 main export
  • jsnext:main: yet again transpiled (fully polyfilled) es6 main export instead of plain sources

I lately found myself asking the package maintaners to either add an esnext field or fix jsnext:main in order to have a reference to plain sources.
No success so far because the first thing they do is 1) checking what other popular packages (i.e. react, lodash) are doing and 2) googling what should be done.

The bad news is “no standard still emerged for this” so they just drop the discussion and wait.

Why this issue then?
@sokra as the father of Webpack you have the chance to stand up and make a choice on what should be the standard here and the environment would simply embrace it.
Would you consider this?

Author: Fantashit

1 thought on “Stand up for the jsnext/esnext standard

Comments are closed.