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

[feature / bug?] allow non-"browser" dependancy priority when tree-shaking #4563

Closed
SilentCicero opened this issue May 3, 2020 · 2 comments
Labels
❔ Question Stale Inactive issues

Comments

@SilentCicero
Copy link

Currently, when using tree shaking, parcel will select dependancies "browser" specified build over the actual raw source, this leads to tree shaken builds which are not tree shaken!

Parcel should either select the raw source and not the "browser" builds of dependancies or allow me to remove that option.

I have tried hacking it myself and removing my dependancies "browser" property from their package JSON, but parcel doesn't seem to handle it all very well.

To recreate, npm init a package, create an index.js and index.html, install ethers module and import it into your build, than do a parcel build with tree shaking enabled. You will see it includes the entire minified browser specified ethers.min.js and no a tree shaken version of ethers.

@SilentCicero SilentCicero changed the title allow browser or non-browser tree-shaking bundle option. allow browser or non-browser tree-shaking bundle option May 3, 2020
@SilentCicero SilentCicero changed the title allow browser or non-browser tree-shaking bundle option [feature / bug?] allow browser or non-browser tree-shaking bundle option May 3, 2020
@SilentCicero SilentCicero changed the title [feature / bug?] allow browser or non-browser tree-shaking bundle option [feature / bug?] allow non-"browser" dependancy priority when tree-shaking May 3, 2020
@mischnic
Copy link
Member

mischnic commented May 4, 2020

The problem is that the browser entry might have different behaviour than main or module and that there is no established browserModule field (not even with the new package.json#exports: #4155).

@github-actions
Copy link

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs.

@github-actions github-actions bot added the Stale Inactive issues label Oct 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
❔ Question Stale Inactive issues
Projects
None yet
Development

No branches or pull requests

2 participants