-
-
Notifications
You must be signed in to change notification settings - Fork 151
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
Relative imports shouldn't be bundled #78
Comments
this will be imporved only for bundler which supports tree-share, but for browser/deno all exports in |
for example, if you import d3 (esm) in browser using unpkg.com, you may see there are hundreds js files will be imported that takes a lot of time in network, but with esm.sh there are only 32 bundled files need |
For people that want to bundle a particular import it should be opt-in via a URL query string parameter. esm.sh already has the Ideally no bundling of either kind occurs by default, as it can easily break the way vanilla ESM is supposed to work. Bundling is even riskier for esm.sh than in traditional Node.js projects with webpack, because esh.sh doesn't have visibility of the entire project and all dependencies at the time of bundling like webpack in a Node.js project does. Over time modules will start to structure their internal modules to take full advantage of deep imports so Deno and browsers only load the exact code that that's needed. We shouldn't let a few bloated legacy packages block people from architecting efficient modern packages. This issue isn't a nice-to-have, it's a total blocker. There are a bunch of packages I can't use with esm.sh because it's bundling behavior causes all sorts of runtime errors, so I've been using other CDNs. |
@jaydenseric can you please list the packages you can't used? in fact i already tried remove the internal bundling, but some packages is hug with lots of deps that is hard to esm.sh since the server just have 4 cpu cores for the build queue, this let you wait long time until the first build is done! even let's say it's really in cdn cache you also need more time to import those denpencies specially your browser doesn't have any cache. the other idea i want to try is follow the {
"exports": {
"./public": {"import": "..."},
"./public/*": {"import": "..."}
}
} with above settings we don't bundle the |
import { MdOutlinedButton as _MdOutlinedButton } from "https://esm.sh/@material/web@1.0.0-pre.12/button/outlined-button.js?target=es2022";
import { MdTonalButton as _MdTonalButton } from "https://esm.sh/@material/web@1.0.0-pre.12/button/tonal-button.js?target=es2022"; These code will get this error:
Because it bundle same script twice |
At the moment, relative imports within a module are incorrectly bundled into the module, for example:
https://esm.sh/graphql-react@15.0.0/public/index.mjs
If you then open https://cdn.esm.sh/v43/graphql-react@15.0.0/es2020/public/index.mjs.js :
File contents…
This is not right at all. This is what the file is supposed to contain:
https://unpkg.com/graphql-react@15.0.0/public/index.mjs
File contents…
If your app imports the same module via the index, and the deep import where it actually lives, it should result in the same code being cached and used instead of duplicates in separate bundled code:
It's important the same code is cached and used so that:
instanceof
checks can work.The text was updated successfully, but these errors were encountered: