Why don't you add ES5 transpiled code to your modules for browsers?

[SamVerschueren]

Noticed more and more questions about adding ES5 files to your projects. The reason is off course that we started dropping support for older Node versions. So I expect more questions in the future. Same situation as #439. I want to be able to link your answer so that people don't have to take me on my word when I answer and close.

[ewnd9]

I looked through the is:issue user:sindresorhus transpile GitHub search results and I think this is look like a statement you can share facebook/create-react-app#1125 (comment) (linked from sindresorhus/file-type#70 (comment))

I think you're asking too much of module maintainers. I target Node.js 4 for modules I make. If users wants them to run in older browsers, it's up to them to transpile. I'm not interested in having a compile step in all my modules.

Maybe there could be a Babel feature (or another tool) that checks the "engine" package.json field in dependencies and decides which dependencies to transpile. Caching should also help, so a dependency is only transpiled once and cached forever for that version.

---

I wonder about tooling:

• Is there a chrome extension which shows engine from package.json on repository pages?
• Is there a webpack plugin which throws error if bundled code contains es6?

[oligot]

I also faced this problem (using a library in the browser that is written in ES2015) when using jspm: jspm/registry#985.
In the meantime, I've switched to Rollup (for various reasons) and I found another way to solve it.
The basic idea is to decouple the bundling task from the transpilation task:

1. bundle the application code as well as all the dependencies (example)
2. transpile the bundle from ES2015 to ES5 (example)

This way, we don't have to specify which dependency is written in ES2015.
Moreover, this opens the door to further explorations like serving non-transpiled ES2015 code in browsers that support it, as currently tested by Netflix.

I don't exactly know how this could be applied to Webpack as I'm not familiar with it.

[sindresorhus]

While most of my modules also work in the browser, I make them mainly for Node.js. I love how dependencies in Node.js just work without having to resort to a bundler, compile-step, and a huge config file. Just npm i -S foo, require('foo'), and npm start to run ❤️. The web on the other hand is a mess. I don't think it's fair to expect every maintainer to give up all this niceness just so that you can slightly simplify an already complicated build-step. It would also be hard for individual packages to know what Babel config to use. Should it include polyfills for newer JavaScript APIs? That might have adverse affect on other dependencies expecting native APIs. Should it compile to ES5 or ES3? Some users might still need ES3 support.

I think this problem should be solved by Babel or bundlers like webpack. One solution would be to automatically check the "engine" field in the package.json of dependencies and decide which dependencies to transpile. Babel has pretty good caching, so it would only transpile the ES2015-written dependencies once per version.

[sindresorhus]

Is there a chrome extension which shows engine from package.json on repository pages?
Is there a webpack plugin which throws error if bundled code contains es6?

Not that I'm aware of. People more familiar with webpack might be able to answer the second question.

[sindresorhus]

@TheLarkInn @hzoo Could we maybe take this discussion and facebook/create-react-app#1125 to a new Babel or webpack issue?

[nolanlawson]

@sindresorhus FWIW this was also discussed a bit in w3ctag/polyfills#6 and I think we came to similar conclusions as you. There maybe ought to be some kind of specification in package.json for different engines/browsers/ESversions ala "browser" or "engines".

[TheLarkInn]

So yeah, as webpack'y answer would specify that bundling sources are good and that leveraging tools like babel-preset-env to transpile based on target only specific features is a good start.

However I know that's not a all encompassing solution for everyone.

[elektronik2k5]

@sindresorhus,

While most of my modules also work in the browser, I make them mainly for Node.js. I love how dependencies in Node.js just work without having to resort to a bundler, compile-step, and a huge config file. Just npm i -S foo, require('foo'), and npm start to run ❤️. The web on the other hand is a mess. I don't think it's fair to expect every maintainer to give up all this niceness just so that you can slightly simplify an already complicated build-step. It would also be hard for individual packages to know what Babel config to use. Should it include polyfills for newer JavaScript APIs? That might have adverse affect on other dependencies expecting native APIs. Should it compile to ES5 or ES3? Some users might still need ES3 support.
I think this problem should be solved by Babel or bundlers like webpack. One solution would be to automatically check the "engine" field in the package.json of dependencies and decide which dependencies to transpile. Babel has pretty good caching, so it would only transpile the ES2015-written dependencies once per version.

I understand your rationale and that's legit and fine! Please consider documenting this fact clearly in your modules, so people don't waste your and their time opening issues about it.

@TheLarkInn is there any particular recommended way to detect and transpile ESM in webpack without setting up ugly include lists for babel-loader? Perhaps using package.json's engines field?

[sindresorhus]

I understand your rationale and that's legit and fine! Please consider documenting this fact clearly in your modules, so people don't waste your and their time opening issues about it.

The Node.js version I target is documented in package.json in every module I maintain: https://github.com/sindresorhus/camelcase-keys/blob/fa7d9883e8ffb6d98b8d04533f2e0b342c7d35ee/package.json#L12-L14 I'm not going to document anything more than that as I don't target the browser. You're free to use my modules in the browser, but you're on your own.

Ideally babel-loader would detect the Node.js version in the engine field, yes.

[elektronik2k5]

Yeah, I just saw you came up with the same idea a while ago. :)

I'll pay attention to the engines field next time.

[SamVerschueren]

I'm seriously considering forking babel-loader to babel-engine-loader so we can all move on...

[sindresorhus]

Or babel-loader-platypus, because they're awesome.

[hzoo]

@SamVerschueren would appreciate if we could work together on something instead of just making a fork. I asked about this earlier https://twitter.com/left_pad/status/838028823572725761 and seems like although a lot of people are in favor some really didn't want it.

I would be cool with a pkg that just enables env by default with a polyfill

[bokub]

The web on the other hand is a mess. I don't think it's fair to expect every maintainer to give up all this niceness just so that you can slightly simplify an already complicated build-step.

I totally agree with the fact that compiling a module for browsers is often a huge mess and a lot of headaches, there are so many different tools with complex configurations that you easily get lost.

I was tired of that, so I created Lyo, an opinionated compiler that doesn't need any configuration to work. In fact, Lyo is nothing more than a wrapper of other tools, the same way XO is an ESLint wrapper with pre-defined rules.

With Lyo installed globally, transpiling your module for browsers shouldn't be harder than running a single command: $ lyo.

And because you cannot expect every maintainer to provide transpiled code, Lyo also works with other people's modules.

If you need a transpiled version of query-string for example, just run $ lyo get query-string, and it's done.

---

So, I don't think I'll make Sindre change his mind about the idea of providing transpiled code with his modules, but I hope it will help:

• module maintainers who don't want to spend hours configuring and automating complex build steps
• people who are being redirected to this thread and just want a .min.js for their projects

Have a nice day 👍

[sindresorhus]

Create React App 2.0 is out with transpilation of dependencies 🎉