Angular 12 @Use statement causing slow compilation. #22676
Assignees
Labels
Comments
|
We noticed something similar while we were testing out the migration, but the issues usually went away once we migrated all remaining imports of |
jelbourn
changed the title
|
Chatting with the CLI team, it seems like the webpack Sass loader is (at least) a part of the problem here, |
jelbourn
added
area: theming
P2
Actually most of the resolutions (the relative once) happens inside dart-sass and therefore we cannot cache them. That said we are looking into improving the sass compilation times in general by using the sync version of dart-sass angular/angular-cli#20740 |
|
Got it, I likely misunderstood Keen yesterday. I chatted with @crisbeto just now and he's going to look into also cutting down the number of module resolutions in general. For anyone coming to this issue: we're hoping to land improvements in a patch release follow-up to 12.0.0. |
|
Can you please provide the exact version of Angular Material and Angular CDK that
Did you run https://sass-lang.com/documentation/cli/migrator on your project at all? |
|
Hi I did not use the sass migrator at all. |
|
That's where things could've been messed up. Between rc.2 and rc.3 we fixed several cases that the migration didn't catch and we moved it from |
|
I chatted with the Sass team a bit today too, and they have sass/sass#2745 which tracks not caching stuff between compilations. They're going to starting investigating to see how much work it would be to add support for more caching. |
|
@ganySA are you able to share a reproduction? It would be useful for someone on the Sass team to see a real-world scenario related to sass/sass#2745 |
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
May 13, 2021
…for the legacy theming bundle Currently the legacy `material/theming` bundle is set up to forward a few top-level `.import` files. The problem is that those files have been auto-generated to be backwards-compatible even for deep imports which means that they have a lot of overlapping `@forward` and `@import` statements. This results in a significant increase in build times for consumers still using the old bundle. These changes address the issue by introducing new shallower `*-legacy-index.scss` files which only export the APIs from the specific package and which in turn are re-exported through the top-level `material/theming` file. The change appears to cut the down the production build time on material.angular.io before the @use migration by more than 60%. Fixes angular#22676.
|
@jelbourn let me know who and i can share the repo they can then build. Do you need it pre update or post? |
|
@crisbeto, I don't think the mentioned PR solved this issue. @ganySA is using the new API, ie: Timings using the new API (v12.0.0-rc.2)
Timings using the old API (v11.2.12)
|
|
@alan-agius4 are there any leftover references to |
|
@crisbeto no there are no references to |
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
May 15, 2021
…for the legacy theming bundle Currently the legacy `material/theming` bundle is set up to forward a few top-level `.import` files. The problem is that those files have been auto-generated to be backwards-compatible even for deep imports which means that they have a lot of overlapping `@forward` and `@import` statements. This results in a significant increase in build times for consumers still using the old bundle. These changes address the issue by introducing new shallower `*-legacy-index.scss` files which only export the APIs from the specific package and which in turn are re-exported through the top-level `material/theming` file. The change appears to cut the down the production build time on material.angular.io before the @use migration by more than 60%. Fixes angular#22676.
15 tasks
1 task
This was referenced May 17, 2021
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
May 17, 2021
…for the legacy theming bundle Currently the legacy `material/theming` bundle is set up to forward a few top-level `.import` files. The problem is that those files have been auto-generated to be backwards-compatible even for deep imports which means that they have a lot of overlapping `@forward` and `@import` statements. This results in a significant increase in build times for consumers still using the old bundle. These changes address the issue by introducing new shallower `*-legacy-index.scss` files which only export the APIs from the specific package and which in turn are re-exported through the top-level `material/theming` file. The change appears to cut the down the production build time on material.angular.io before the @use migration by more than 60%. Fixes angular#22676.
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
May 17, 2021
…for the legacy theming bundle Currently the legacy `material/theming` bundle is set up to forward a few top-level `.import` files. The problem is that those files have been auto-generated to be backwards-compatible even for deep imports which means that they have a lot of overlapping `@forward` and `@import` statements. This results in a significant increase in build times for consumers still using the old bundle. These changes address the issue by introducing new shallower `*-legacy-index.scss` files which only export the APIs from the specific package and which in turn are re-exported through the top-level `material/theming` file. The change appears to cut the down the production build time on material.angular.io before the @use migration by more than 60%. Fixes angular#22676.
andrewseguin
pushed a commit
that referenced
this issue
May 18, 2021
…for the legacy theming bundle Currently the legacy `material/theming` bundle is set up to forward a few top-level `.import` files. The problem is that those files have been auto-generated to be backwards-compatible even for deep imports which means that they have a lot of overlapping `@forward` and `@import` statements. This results in a significant increase in build times for consumers still using the old bundle. These changes address the issue by introducing new shallower `*-legacy-index.scss` files which only export the APIs from the specific package and which in turn are re-exported through the top-level `material/theming` file. The change appears to cut the down the production build time on material.angular.io before the @use migration by more than 60%. Fixes #22676.
andrewseguin
pushed a commit
that referenced
this issue
May 18, 2021
…for the legacy theming bundle Currently the legacy `material/theming` bundle is set up to forward a few top-level `.import` files. The problem is that those files have been auto-generated to be backwards-compatible even for deep imports which means that they have a lot of overlapping `@forward` and `@import` statements. This results in a significant increase in build times for consumers still using the old bundle. These changes address the issue by introducing new shallower `*-legacy-index.scss` files which only export the APIs from the specific package and which in turn are re-exported through the top-level `material/theming` file. The change appears to cut the down the production build time on material.angular.io before the @use migration by more than 60%. Fixes #22676.
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Please see the link angular/angular-cli#20713
The new theme API is really slow slow and problematic.
It seems related by the move to
@use '~@angular/material'statements. My compilation time with CLI has increased 5x, i am also experiencing node memory issues. Reverting back to 11 does not have this issue.
I have engaged with the CLI team but it seems this issue is material related.
The text was updated successfully, but these errors were encountered: