Support Relative Dynamic Imports

Type of Issue

[ ] Bug Report
[X] Feature Request

Description

Currently when creating a dynamic import inside a library an error is thrown by rollup: Invalid value for option "output.file" - when building multiple chunks, the "output.dir" option must be used, not "output.file". To inline dynamic imports, set the "inlineDynamicImports" option. This prevents creating more optimized libraries. I think that the reason behind this limitation was because of the view engine. Since that is gone, is there anything still holding us back?

Expected Behaviour

Additional chunks are created and no error is given.

Version Information

$ node_modules/.bin/ng-packagr --version
ng-packagr: 15.0.1
@angular/*: 15.0.1
typescript: 4.8.4
rxjs: 7.5.7
node: 18.12.0
npm: 9.2.0

[alan-agius4]

I tested converting all my libraries to have the default export pointing to the “ESM2020” module path and got less 3MB of initial bundle size (unzipped).

The unflattering version does have its drawbacks, it will increase the application build times, and in some cases it does result in larger bundle sizes

If you are seeing increases in bundle size when using FESMs, this typically indicates problems with the library architure and unrelated features into secondary entry-points. Which causes the unrelated code to be bundled in the same FESM.

[Carlosamouco]

If you are seeing increases in bundle size when using FESMs, this typically indicates problems with the library architure and unrelated features into secondary entry-points.

At first I tried to follow that approach, placing every component in a entry point, but I realized that I would need a lot of entry points and that would make the library take minutes to compile… It becomes a hell to develop in that way. That being sad, I do use entry points but to separate unrelated parts of the library. I don’t think that the purpose of entry points should be to lazy load things or to optimize tree shaking… For me that’s more like an workaround to the current limitation. Entry points should be a way to well define the public API of the library. You need to be thinking on so many aspects to have the library full optimized that is almost impossible to make it right, unless as I sad, you create a entry point for every component which does not make sense…

I don’t understand why we can’t have relative dynamic imports and why we don’t use the “ESM2020” export as the default. I read this but I don’t understand what’s the problem…

The unflattering version does have its drawbacks, it will increase the application build times, and in some cases it does result in larger bundle sizes

Can there be an option to define what we want to be the default export? And opt out the rollup flattening?