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 not main entry #65

Closed
dy opened this issue Jun 18, 2019 · 2 comments
Closed

Why not main entry #65

dy opened this issue Jun 18, 2019 · 2 comments

Comments

@dy
Copy link

dy commented Jun 18, 2019

Just a question - I used to create and use many packages with single ‘main’ entry but usable both in browser/node. Now due to this transition to esm we have to generate noise in package.json / dist folder. I thought pika provides graceful solution for web-modules - taking cjs (as I was doing) and compiling that to esm on install, (instead of forcing whole npm to change). That’s obvious there’s a lot of browser legacy cjs modules that aren’t going to transition to esm, like Buffer, tape etc.
Just curious - what’s the strong reason against taking ‘main’ cjs module entry?
Thanks!

@backspaces
Copy link

How do you do that?

compiling that to esm on install

Check #62 which discusses cjs -> es6 via rollup and rollup-plugin-commonjs. Is that your approach? Maybe webpack magic?

@FredKSchott
Copy link
Owner

once Node adds ESM support this will get a lot less noisy, but right now "module" is the only reliably way to detect ESM, which this tool was built specifically for. +1 for following up in #62 about adding CJS backwards compatibility support, which could also help us migrate once Node ESM support goes mainstream.

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