In application builder allow for custom styles plugins, e.g. for SCSS paths mapping needed in monorepo with many libraries

[Platonn]

Command

build

Description

Context - our usecase:
Were' developing a set of Angular libraries in a monorepo, where some libs can cross-import SCSS files from other libs, and they should @import them using "symbolic" library paths (not relative paths). e.g. in a SCSS file inside the lib A (@my-org/*lib-A*/styles ) we'd like to import SCSS from lib B (e.g. @import '@my-org/*lib-B*/styles' ).

Solution with old webpack builder:
With the old Angular browser builder it was possible to apply SCSS paths mapping by applying a custom webpack plugin (e.g. using a 3rd party builder @angular-builders/custom-webpack:browser which extended the default Angular browser builder). See the example defining of paths mapping:

• example nx project.json (but can be angular.json ) in our repo: https://github.com/SAP/spartacus/blob/30540a7957989c7ab520704bd2a09220454eaa15/projects/storefrontapp/project.json#L10-L14
• example extra-webpack.config.js in our repo: https://github.com/SAP/spartacus/blob/30540a7957989c7ab520704bd2a09220454eaa15/extra-webpack.config.js#L24-L79

Problem after migrating to esbuild application builder:
After migrating to the new Angular application builder, which is based on esbuild, such a paths mapping no longer works (even when passing analogical custom plugin e.g. via the 3rd party @angular-builders/custom-esbuild:application).

Note: we tried passing a custom plugin to buildApplication()'s 3rd argument extensions.codePlugins, but it didn't affect the SCSS paths resolution. Maybe we did something wrong. I guess it's becasue the styles plugins defined in the array below don't take the ambient extensions.codePlugins into account. See the source code of Angular CLI:

angular-cli/packages/angular/build/src/tools/esbuild/stylesheets/bundle-options.ts

Lines 61 to 66 in 936bda1

	const plugins: Plugin[] = [
	pluginFactory.create(SassStylesheetLanguage),
	pluginFactory.create(LessStylesheetLanguage),
	pluginFactory.create(CssStylesheetLanguage),
	createCssResourcePlugin(cache),
	];

Note 2: I understand that buildApplication() has a JSDoc comment "@experimental Direct usage of this function is considered experimental.". That said, I'm still hoping we can help improve this function with our feedback, so it addresses needs of authors of custom Angular libraries developed in monorepos.

Describe the solution you'd like

It would be nice to be able to inject into buildApplication() custom plugins affecting SCSS paths resolution e.g. into the plugins array in ..../tools/esbuild/stylesheets/bundle-options.ts.

Describe alternatives you've considered

Workaround ideas:
Our ultimate goal is to keep our example app in our monorepo working. And publish our libs so their consumers can import them and it should work in their apps.

So alternatively we can keep relative paths in our monorepo (e.g. @import '*lib-b*/....' . And as a post-build step of a production build of an Angular library (with ng-packgr) we could search-replace with a regex in the /dist folder all the cross-library scss import paths to relevant "symbolic" paths (.e.g @import *@my-org/lib-b*/....
Thanks to this, the example app in our monorepo using relative paths would still work (no need for paths mapping in the application builder). And users of our libraries would get shipped SCSS sources which are cross-importing other libs' styles via symbolic paths, which will resolve successfully (using their node_modules/*@my-org/lib-b*/... )
The downside of it is that our example app in our monorepo would differ from our user's apps - which would be a bit confusing to read (and ambigious to diffrentiate it from non-cross-lib other relative imports from inside the same library itself).

Note: I've found a related issue #23552 but it's old and related to the webpack builder, where workaround with custom webpack plugin was possible. I've created this issue for the purpose of application builder, where I hope we could add an API for injecting a custom plugin affecting SCSS (e.g. for a custom paths mapping).

[clydin]

Have you considered and/or tried using the package manager's workspace functionality? This should allow each of the separate style libraries to participate in the preexisting node module resolution process. The need to manually create path mapping rules in a custom config file for each would also be eliminated.

Most commonly used package managers have variations of the workspace feature. The Angular code itself currently uses pnpm with its workspace functionality quite extensively across its repositories.

[Platonn]

Hi @clydin, thank you for the hint! 🙌 We started using the "workspaces" feature of npm and it helped.

Let me close this issue, becasue the feature request is no longer needed for us.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}