-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Split independent chunks by entrypoint name in bundle (preserve module hierarchy) #492
Comments
I'm exploring I have 8 entry points corresponding to 8 source folders (it's a monorepo), but the output has those 8 entry points + an additional 15 chunks. 😳 While more code splitting might result in less total code being loaded when someone imports a given method, this would also avoid more round-trips if used directly in production. In our case, we've already tried to split up the project along what we think is a reasonable breakdown. |
FWIW, rollup used to generate the output that is desired here with |
I can't promise that entry points will ever be able to import each other like that since entry points are special and may sometimes need special handling. For example, the upcoming top-level await feature will require each entry point to evaluate the top-level await state machine, and importing one entry point into another would mess this up. Doing manual chunk assignment in the general case while maintaining the correct import order (especially with top-level await) requires the ability to lazily defer code execution ESM files. This is pretty complex but I'm already partway through implementing this and I hope to be able to get it in sometime in the next month or two. I believe manual chunk assignment is currently being tracked by #207 and #268. |
Admittedly I was fairly naive wrt the complexity of the request in this issue. (I'd originally opened it because I'd seen the output I'd expected in rollup pre-2.0, which has now been dropped and the ESM output is similar to esbuild |
This is a hacky implementation of: - evanw/esbuild#207 - evanw/esbuild#492 If either of those are implemented, most of this should be obsolete. For now, we will use this build in CI to enforce an impohgra graph among the `cubing/*` modules.
This is a hacky implementation of: - evanw/esbuild#207 - evanw/esbuild#492 If either of those are implemented, most of this should be obsolete. For now, we will use this build in CI to enforce an import graph among the `cubing/*` modules.
We're waiting on evanw/esbuild#492 to split the build properly. The code I wrote to try to get that working ended up being more practical for enforcing import graph restrictions.
We're waiting on evanw/esbuild#492 to split the build properly. The code I wrote to try to get that working ended up being more practical for enforcing import graph restrictions.
We're waiting on evanw/esbuild#492 to split the build properly. The code I wrote to try to get that working ended up being more practical for enforcing import graph restrictions.
Loving
esbuild
! Thanks for all the hard work pushing this forward.I have a project with several tree-shakeable submodules and a top-level
index.ts
that simply export these default modules by name. Bundling with multiple entrypoints (and--splitting
), I would expect the module hierarchy to be preserved using the named entrypoints, rather than producing unique chunks that are imported independently by each entrypoint. As an example,Where each entrypoint imports a unique combination of chunks, and
index.js
does not importadd.js
orsubtract.js
. I would instead expect something like Rollup produces (or whatesbuild
produces when entrypoints aren't within a hierarchy):which reduces the number of chunks and preserves the structure of imports. Instead
index.js
would look something like:I don't think this is related to #399, and couldn't find another related issue. Apologies if I've missed something!
The text was updated successfully, but these errors were encountered: