Re-introduce file splitting optimization

[alan-agius4]

Code motion/splitting does not seem to work as expected and in some cases this causes non optimal chunks to be created.

Example:

entry-one.js

export {foo2} from './file3.js'

entry-two.js

export {foo} from './file3.js'

file3.js

export const foo = 'foo';
export const foo2 = 'foo2';

The generated common chunk contains the following: chunk-QXQWH7T5.js

// file3.js
var foo = "foo";
var foo2 = "foo2";

export {
  foo,
  foo2
};

However, since foo and foo2 are never referenced in the same entry-point, the expected behaviour would be that esbuild generates 2 chunks.

chunk-YYY.js

// file3.js
var foo = "foo";

export {
  foo
};

chunk-XXX.js

// file3.js
var foo = "foo2";

export {
  foo2
};

Repro https://esbuild.github.io/try/#YgAwLjE5LjgAewogIGJ1bmRsZTogdHJ1ZSwKICBzcGxpdHRpbmc6IHRydWUsCiAgZm9ybWF0OiAnZXNtJywKICBvdXRkaXI6ICcvJywKfQBlAGVudHJ5LW9uZS5qcwBleHBvcnQge2ZvbzIsIGZvbzN9IGZyb20gJy4vZmlsZTMuanMnAGUAZW50cnktdHdvLmpzAGV4cG9ydCB7Zm9vfSBmcm9tICcuL2ZpbGUzLmpzJwAAZmlsZTMuanMAZXhwb3J0IGNvbnN0IGZvbyA9ICdmb28nOwpleHBvcnQgY29uc3QgZm9vMiA9ICdmb28yJzsKZXhwb3J0IGZ1bmN0aW9uIGZvbzMgKCkge30

Version 0.19.8

Related to https://github.com/angular/angular-cli/issues/26622

[montella1507]

@evanw any news? It can lead to extreme difference in initial loading times etc.

Check linked issue above, please.

For the instance:

• when you have 100+ icons (1 .ts file per 1 SVG icon)
• reexported in index barel file
• imported from barel file

It forces developer not to use imports from barel, even in cases when it is definitely legit (public_api file etc)

[LanderBeeuwsaert]

isn't the rolldown announcement also related with this? https://rolldown.rs/about

[montella1507]

I would say so.

Code splitting Is way worse in esbuild than in webpack.

Initial part of our pplications got bigger for 150+ kBs because of that, in different cases And we do not really want to "deep import" And Have 100+ entry points fór every library.

Creating of 100 secondary entry points for 100 icons Is would be nonsense

[YangYongAn]

Looking forward to enhancing the manual custom chunks capability. I feel that although it is difficult and may affect efficiency, it is indeed very useful at certain times.

[sod]

Code splitting Is way worse in esbuild than in webpack.

Thats a bit harsh. I'd call the code splitting 1) straight forward and 2) some limitations for the sake of build performance. IMO a final pass for chunk optimization would go a long way already. Just like the minChunkSize in webpack is a plugin meant for production optimization.

Only issue is, that in native es modules you can't "just throw together" small chunks. As then you'd also merge the imports. But from looking at our chunk structure that esbuild produces, going back to commonjs or amd to be more flexible may be overkill. Pulling up those small <500 byte chunks into their parents could already be sufficient.

[montella1507]

https://github.com/angular/angular-cli/issues/26622#issuecomment-1849856262 you did not get answer, already?

[montella1507]

@evanw please...

Could you reconsider the importance of this issue? This is really problem for production apps...

This is initial bundle of the application.. Only 3 icons are used in initialChunk, however ALL icons are packed together in ESBUILD... why are we fighting for (for the instance) removing 50kB from Angular via zone.js when esbuild will pack 300kB of icons together...?

Are we really supposed to be forced to create secondary entry point for every icon???

In webpack.. icons are split between like 20 chunks (by usage), or packed directly inside others "lazy loaded feature packs"...