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

Provide ES5 version for browser environment #13

Closed
sqal opened this issue Mar 24, 2017 · 12 comments
Closed

Provide ES5 version for browser environment #13

sqal opened this issue Mar 24, 2017 · 12 comments

Comments

@sqal
Copy link

sqal commented Mar 24, 2017

Hi @sindresorhus. Can you please provide ES5 version so it can work in older browsers that doesn't support arrow functions and other goodies. I use webpack and babel-loader in my project but I don't transpile any modules from node_modules directory:

  test: /\.js$/,
  exclude: /node_modules/,
  loader: 'babel-loader',
}

So.. it would be to at least have a choice between ES5 and ES6 version. Thanks :)

@SamVerschueren
Copy link

We aim for Node.js, not the browser. You can find a more detailed explanation here sindresorhus/ama#446

@sindresorhus
Copy link
Owner

I encourage you to open an issue on https://github.com/webpack/webpack/issues about including support for automatic transpiling of node_modules that need it.

@stevemao
Copy link
Contributor

You don't need to open an issue there. Just don't exclude modules like this for babel-loader.

@sqal
Copy link
Author

sqal commented Mar 24, 2017

Thanks for explanation and help guys. I decided to just add this module to the paths transformed by the babel-loader

include: [
  paths.appSrc,
  path.join(paths.appNodeModules, 'sort-on'),
]

@sindresorhus
Copy link
Owner

@stevemao Yes, they do. I'm tired of getting issues like this on all my repos. It's better if Webpack resolved this.

@SamVerschueren
Copy link

@sindresorhus Jup, that's why I have it as a saved reply ;)

screen shot 2017-03-24 at 13 40 52

@stevemao
Copy link
Contributor

@sindresorhus I don't see how this fit in webpack either.
@sqal I have made a module for you: https://github.com/stevemao/sindre-module-paths
You can do this:

const path = require('path')
const sindreModulePaths = require('sindre-module-paths')

// Then in some async function
const es6ModulePaths = await sindreModulePaths();

{
  test: /\.js$/,
  include: [
    ...es6ModulePaths,
    path.resolve(__dirname, 'src'),
  ],
  use: 'babel-loader',
}

Let me know if you have any questions :)

@SamVerschueren
Copy link

Can't we just detect if the engines field is set to Node.js 4+? Then we would have a general solution that works if the field is being used correctly. If it's not present, people can always add a PR. Sindre always uses it so that's covered.

@sindresorhus
Copy link
Owner

Can't we just detect if the engines field is set to Node.js 4+?

Yes, I've suggested that to both the Babel and Webpack maintainers.

@sindresorhus
Copy link
Owner

sindresorhus commented Mar 25, 2017

@stevemao 🙄

I'm not the only one targeting Node.js 4 these days, fwiw.

@sindresorhus
Copy link
Owner

This is such a typical front-end attitude. Instead of actually trying to fix the core problem, you independently create different layers of indirections that just works around part of the problem.

Repository owner locked and limited conversation to collaborators Mar 25, 2017
@sindresorhus
Copy link
Owner

@stevemao You know could have actually made a useful module if you checked the "engine" field instead.

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

4 participants