You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
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).
The text was updated successfully, but these errors were encountered:
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 Angularbrowser
builder). See the example defining of paths mapping:project.json
(but can beangular.json
) in our repo: https://github.com/SAP/spartacus/blob/30540a7957989c7ab520704bd2a09220454eaa15/projects/storefrontapp/project.json#L10-L14extra-webpack.config.js
in our repo: https://github.com/SAP/spartacus/blob/30540a7957989c7ab520704bd2a09220454eaa15/extra-webpack.config.js#L24-L79Problem 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 argumentextensions.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 ambientextensions.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
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 theplugins
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 theirnode_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).The text was updated successfully, but these errors were encountered: