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

Comments

@SamVerschueren
Collaborator

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Owner

sindresorhus commented Feb 20, 2017

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

@nolanlawson

This comment has been minimized.

nolanlawson commented Mar 7, 2017

@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

This comment has been minimized.

TheLarkInn commented Mar 7, 2017

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

This comment has been minimized.

elektronik2k5 commented Mar 25, 2017

@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

This comment has been minimized.

Owner

sindresorhus commented Mar 25, 2017

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

This comment has been minimized.

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

This comment has been minimized.

Collaborator

SamVerschueren commented Mar 27, 2017

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

@sindresorhus

This comment has been minimized.

Owner

sindresorhus commented Mar 27, 2017

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

@hzoo

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Owner

sindresorhus commented Oct 2, 2018

Create React App 2.0 is out with transpilation of dependencies 🎉

@zavr-1

This comment was marked as spam.

zavr-1 commented Oct 2, 2018

Epic I don't want to transpile anything as I also write for Node :P @sindresorhus you can use import and export in your packages without Babel by installing my regex-based transpiler alamode: https://github.com/a-la/alamode! It's super-fast, has a require hook and works without building any AST! You can even debug with no problems.
For example, I love the import syntax because it's a language feature therefore should be used, but I don't care about all this ECMA Modules stuff like async loading, I just want to write beautiful code for Node, and ALAMODE is the way to do it! Since Node 10 still doesn't support modules, but works with everything else, it is the most relevant and light-weight solution today. There is literally no alternative to Babel to do that -- please support my project? There currently is no caching, but it will be there shortly (also because it's fast there isn't a need really). I will also add an ability to write

require('alamode')()
import example from 'example'

in the same file which is not possible with babel/register! Also for everyone's information, up until I don't know what beta-7, Babel used to destroy any JSDoc in files, e.g., it would do this:

/**
 * Make a rule for pasting markers back.
 * @param {Marker} marker A marker used to cut and paste portions of text to exclude them from processing by other rules.
 * @returns {Rule} A rule to paste previously replaced chunks.
 */
exports.makeCutRule = makeCutRule;

const makePasteRule = marker => {
  const {
    regExp: re,
    map
  } = marker;
  const rule = {
    re,

    replacement(match, index) {
      const m = map[index];
      delete map[index];
      return m;
    }

  };
  return rule;
};

And nobody had noticed apart from me! And this is a project used by hundreds of thousands of people and considered essential! Screw the corporate Babel, support indie ÀLaMode!!!

@sindresorhus

This comment was marked as resolved.

Owner

sindresorhus commented Oct 5, 2018

@zavr-1 This is not the place to advertise your project. Try submitting to JavaScript Weekly newsletter and Reddit instead.

For ES2015 module syntax, there's also esm.

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.