Separation of code splitting purposes

[MrSimsure]

As stated by the esbuild site the two main objective of code splitting are

• Code shared between multiple entry points
• Code referenced through an asynchronous import()

Could having two separate options for thoose types of situation be a good addition?
In my current case i have a react project with some pages and components, a simple nodejs server serve the client files.
But with the exception that some components can be avaiable or not to some user, so if for example the components are:

• navbar
• sidebar
• info_button
• shop_button

All this components are referenced in the main page, but shop_button is imported with an asynchronous import(), so it produce a separate chunk when building (with code splitting enabled).
this way when from the server i block the shop button files for a specific client the page doesn't load them and show a react Error Boundaries instead.
This works perfectly, but in the build folder the resulted js files are: index.js (the main bundle with all pages and components), shop_button.js (the async imported component), and two general chunks.js wich seems to contains some react shared code wich both the sync imported components and the async imported component referenced.

As thoose two chunk contains the base react lib for the site to work i will always load them, so it would be a better optimization to include them in the main index.js file like everything else and don't make the client always download two additional js files.

Could this separation of code splitting cases become a possible new option? One for shared code and one for async imports?

[evanw]

As thoose two chunk contains the base react lib for the site to work i will always load them, so it would be a better optimization to include them in the main index.js file like everything else and don't make the client always download two additional js files.

That's not necessarily better, depending on what you're optimizing for. Some people want to optimize for subsequent page loads instead, and don't want for clients to re-download shared code that hasn't changed since the last page load.

Could this separation of code splitting cases become a possible new option? One for shared code and one for async imports?

I believe you should be able to do this by just running esbuild once per entry point with code splitting enabled. Is there a reason that doesn't work for you?

[MrSimsure]

That's not necessarily better, depending on what you're optimizing for. Some people want to optimize for subsequent page loads instead, and don't want for clients to re-download shared code that hasn't changed since the last page load.

Working mainly on single page web app, i prefer to have the less number of files and cache them with a service worker, and even if really not that important also for a "clean" view of the distribution folder.

I believe you should be able to do this by just running esbuild once per entry point with code splitting enabled. Is there a reason that doesn't work for you?

I have only one entry point, the main index.jsx file that start the react project, this file reference a page, let's call it "home", and home reference the components mentioned above.
So my entry point is always a single file and i run esbuild one time targeting it. But the results are the ones i exposed.

[evanw]

Ah in that case there isn't a way to do this. If both the entry point and the dynamically imported file use the same shared library, that shared library needs to be in a third file so that it can be imported into both the entry point and the dynamically imported file.

It's not an option for esbuild to duplicate the shared code into both the entry point and the dynamically imported file. It's not just an optimization; this is actually a correctness issue. Having duplicate copies of a library can easily introduce behavior changes and bugs.

It's also not an option for esbuild to put the shared code in the entry point file and reference it from the dynamically imported file. That would mean exposing the shared code as an export of the entry point file which would change the set of external exports for the entry point file, which would be an incorrect compilation.

It may be possible for esbuild do this when code splitting is enabled for the iife output format, which I plan to look into later this year. As you can tell, esbuild's code splitting support is still a work in progress (which is why #16 is still open). If you want a tool with mature code splitting support that lets you change these kinds of things, I recommend that you use another tool instead.

[MrSimsure]

Ok i see how it works now.
I will stick with esbuild, iife code splitting could be a solution in the future, so i will wait for it and keep the things as they are for now.
Thanks.