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

Distributing ES2015 code is not user friendly #1

Closed
kimmobrunfeldt opened this issue Jul 22, 2016 · 3 comments
Closed

Distributing ES2015 code is not user friendly #1

kimmobrunfeldt opened this issue Jul 22, 2016 · 3 comments

Comments

@kimmobrunfeldt
Copy link

kimmobrunfeldt commented Jul 22, 2016

First of all, I know there is no good solution to this.

This module uses ES2015 code as of 2.0.0 release https://github.com/sindresorhus/strip-indent/blob/v2.0.0/index.js. It makes using this module in our frontend code hard. We have these options:

  1. Babelify all our external dependencies https://github.com/babel/babelify/tree/6d45fa84762f3b57a4b7bef0e1bbdf484614f74d#faq that would be too slow. (our problem)

  2. Maintain a list of our ES6 code dependencies and only babelify those with the ignore and global options provided by babelify. This requires quite a lot of wasted maintenance from all app developers. (our problem)

  3. Use 1.0.1 version of this module. This option loses maintenance for the module. (no one's problem)

  4. The original module would release dist version of the module as ES5 code to NPM. (your problem)

    I personally think this is the best solution for now. For frontend and backend(< node 4) app developers requiring an ES6 module is in practice comparable to using a NPM module which has released their source code as CoffeeScript because using the module requires a build step. Ideally there could be a dedicated JS version attribute in package.json or some similar general purpose solution from NPM.

  5. package.json should have a convention which indicates the JS version the package uses. (NPM's problem)

What do you think would be the best solution at this moment when we need to ship code that runs on older browsers too? And what would be the ideal solution? I'm interested about hearing your opinion. I didn't find this question yet at your ama repo.

@sindresorhus
Copy link
Owner

Not really something I care about, sorry. I make these modules for my own needs for use in Node.js. They do work fine in newer browsers, but it's up to you to make it work in older browsers if you need that. I don't really have any better solution than what you suggested. I would probably have used Webpack to create a bundle of only the needed JS and then run everything through Babel. That would probably be faster than running the whole dependency tree through Babel.

package.json should have a convention which indicates the JS version the package uses. (NPM's problem)

I already indicate which Node.js version I target in package.json, which should give an indication of the targeted JS version.

@AndersDJohnson
Copy link

@kimmobrunfeldt @sindresorhus I've created a webpack helper to automatically detect dependencies such as this one that may require Babel transpilation. See https://github.com/andersdjohnson/webpack-babel-env-deps. I'd love for you to try it, and star if you like. Feedback welcome. Perhaps more features to come.

@AndersDJohnson
Copy link

AndersDJohnson commented Jul 27, 2017

@kimmobrunfeldt @sindresorhus FYI there was an npm publish issue and other issues with webpack-babel-env-deps <1.2.4 - if you were trying to use, please upgrade.

jamiebuilds pushed a commit to Thinkmill/react-markings that referenced this issue Aug 30, 2017
The strip-indent package doesn't use any kind of transpilation,
but it does use arrow functions. In most environments dependencies
are not transpiled, so using this dependency will lead to issues.
While they're not hard to solve, it is probably a good idea to
just replace the module here, as there doesn't seem to be
any interest upstream to transpile the package:

sindresorhus/strip-indent#1

I have not added a separate file since there's no bundling or
transpilation process in place here either. I hope that's
fine 😄
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants