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

Main entrypoint not compatible with ES5 #40

Closed
kolman opened this issue Jan 10, 2019 · 3 comments
Closed

Main entrypoint not compatible with ES5 #40

kolman opened this issue Jan 10, 2019 · 3 comments

Comments

@kolman
Copy link

kolman commented Jan 10, 2019

I know it was done on purpose, but having the "main" entrypoint in package.json pointing to ES6 module is unfortunate. It can't be easily integrated into project that targets older browsers. Babel does not process node_modules by default and having exception for just one library pollutes the build script.

Proposal: Keep main entrypoint ES5, use "module" or "jsnext:main" for ES6

package.json

...
  "main": "icepick.js", // this is ES5 compatible module
  "module": "icepick.mjs" // this is ES6 module
...
@aearly
Copy link
Owner

aearly commented Jan 12, 2019

If you want an ES5 version of icepick, I'd use version 1.x, which is fully ES5. You can also configure webpack to use icepick.min.js (which compiled down to ES5 as well as minified) in place of the default icepick.js.

I don't want to ship an ES5 version as the main, because benchmarks show the ES2015 version is significantly faster.

@kolman
Copy link
Author

kolman commented Jan 12, 2019

Webpack and it's babel plugin should be able to pickup "module" entrypoint, ES6 version, without any configuration. We use browserify + babel 6 and that's much more pain. Having special config with regex pattern to match just one library does not feel good (besides the fact it does not work anyway, but that can be some bug on our side). We switched to icepick 2 because it has dissocIn, is there a chance to backport it to icepick 1?

@aearly
Copy link
Owner

aearly commented Jan 29, 2019

Sorry, after more thought, I'm not interested in reverting the main back to ES5, especially when there are several workarounds for your use case.

@aearly aearly closed this as completed Jan 29, 2019
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

2 participants