Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
SamVerschueren opened this issue Jan 23, 2017 · 22 comments
Closed

Comments

@SamVerschueren
Copy link

SamVerschueren commented Jan 23, 2017

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
Copy link

ewnd9 commented Feb 5, 2017

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
Copy link

oligot commented Feb 6, 2017

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
Copy link
Owner

sindresorhus commented Feb 20, 2017

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
Copy link
Owner

sindresorhus commented Feb 20, 2017

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
Copy link
Owner

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

@nolanlawson
Copy link

@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
Copy link

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
Copy link

@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
Copy link
Owner

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
Copy link

elektronik2k5 commented Mar 25, 2017

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
Copy link
Author

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

@sindresorhus
Copy link
Owner

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

@hzoo
Copy link

hzoo commented Mar 27, 2017

@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

imyelo added a commit to ambar/wxio that referenced this issue Aug 24, 2018
imyelo added a commit to tinajs/wxio that referenced this issue Aug 24, 2018
imyelo added a commit to tinajs/wxio that referenced this issue Aug 24, 2018
@bokub
Copy link

bokub commented Sep 18, 2018

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
Copy link
Owner

Create React App 2.0 is out with transpilation of dependencies 🎉

@zavr-1

This comment has been minimized.

@sindresorhus

This comment has been minimized.

Repository owner locked as resolved and limited conversation to collaborators Oct 5, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests