Make all Spartacus models augmentable (extendable)

[Platonn]

Current state

Currently we expose only some models (e.g. Product) to be augmentable (extendable) for customers.

Goal

For the great extensibility experience for customers, ideally we should expose all TS models as augmentable. We don't do it currently, because, according to the current approach, it requires a hassle declaring manually all those models in public_api.ts. (which is cumbersome and prone to leftovers).

The reason extendable models must be declared flatly in public_api.ts

Current limitation of Typescript: the models re-exported in public_api.ts via barrels index.ts files (export * from ./local/file) cannot be augmented. See TS issues:

• Interface merge of import/local should error when the import is re-exported with export * microsoft/TypeScript#9532
• Augmenting external module that is re-exported? microsoft/TypeScript#18877

Details of our current solution (which is used only for some models)

To workaround it, in Spartacus we export manually ONLY SOME most-frequently-extended types in the public_api.ts, and then thanks to our custom builder, we copy-paste those types definitions into the main output .d.ts file in /dist folder of a library.

Let's automate flattening d.ts files

We should research how we can automate flattening d.ts files, so all models are declared in the build output public_api.d.ts

Results of preliminary research:

• It would be great if Angular's ng-packagr would allow for flattening d.ts out of the box, see issue Flatten type definitions to a single *.d.ts file ng-packagr/ng-packagr#139
• https://github.com/TypeStrong/dts-bundle seems to do the job, but it says its experimental
• https://github.com/timocov/dts-bundle-generator seems to do the job, but we would need to verify correctness of this tool
• https://github.com/Swatinem/rollup-plugin-dts seems to do the job, but requires rollup (not sure if we can use it)
• The Angular team has built their own custom naive mechanism for flattening their d.ts files when packaging their libraries, however the mechanism has some limitations (as this comment says). Maybe we could reuse this logic, if only we understand and accept the limitations.