Ok, I feel like I have to go a bit deeper.
Here is the thing:
ng-packagr has a completely custom build chain. The chain is based on transforms and pipelines (read more here).
This architecture is extensible to some degree however it’s nearly impossible to do what you want. If the
STYLESHEET_TRANSFORM was implemented it would have been a easier but unfortunately it’s not implemented, despite being mentioned in one of the examples.
Let’s start with your first idea -
rollup is used by
ng-packagr solely for bundling purposes, it doesn’t take any part in compilation and file processing.
rollup is applied inside
WRITE_BUNDLES transform, which is implemented, and it even has an option for custom plugin. Since
WRITE_BUNDLES is an existing transform, theoretically it could be replaced with a custom provider. However,
rollup is applied deep inside this transform so you would have to basically copy-paste the entire transform tree down to the rollup function in order to be able to add your custom plugin. Which, obviously, can break with every minor release. But even when you did that it wouldn’t solve your problem entirely.
rollup is processing only
umd bundles and in library build you also have
esm modules which are not processed by
Let’s face it - you cannot modify
rollup process in order to change the final bundle.
Your another option is to try replacing the
compileNgcTransform with a custom one which mimics its behavior but passes to
compileSourceFiles function a custom
stylesheetProcessor, which, in turn, is the same processor as the default but applies additional
This can be easily broken by a minor release too (since you copy-pasted the whole build pipeline) and it’s also hardly maintainable.
Moreover, if you managed to replace the whole pipeline and applied your post css plugin you still have to modify the html. Which you can’t do inside the build process, because HTML and TS processing is done by
ng compiler host and there is no way to hook into it. You’ll have to override the compiler host, and believe me, you don’t want it.
So you’ll still have to go to the final bundle/modules and somehow replace the class names with hashes that are written during the build process to a json file.
As you can see there is almost no way to do what you want with
In my opinion your best shot is to try modifying the final bundles/modules with a custom post-build script.