Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bug]: cms-adapters:style extractor takes too much time #2272

Open
julienama opened this issue Oct 10, 2024 · 4 comments · May be fixed by #2586
Open

[Bug]: cms-adapters:style extractor takes too much time #2272

julienama opened this issue Oct 10, 2024 · 4 comments · May be fixed by #2586

Comments

@julienama
Copy link

julienama commented Oct 10, 2024

Package name

extractors

Package version

11.0.4

Reproduction steps

Create a library with many components having stylings
Run yarn run cms-adapters at root
Notice the time it takes for nx run @mypackage:"cms-adapters:style"

Current result

In our case, this cms-adapters:style step is taking ~7m30s for a package containing around 100 components

Expected result

Can we optimize the process to reduce the processing time? As globally this step has a high impact on our current build statistics.

Additional comments

@kpanot
Copy link
Contributor

kpanot commented Oct 11, 2024

@julienama ,

Thank you for the report.
The process cms-adapters:style is actually using the Sass API and rebuild each Sass files matched by its input patterns.
The performance issue can be due to import of a large amount of Sass dependencies (direct or indirect) in every Sass parsed.

Is it a new issue you faced after an update of the Otter library? Can it be due to an update or your Sass architecture on your side? Or is it an issue you have since long time?

@julienama
Copy link
Author

The issue started when we added the extraction and check of the CMS metadata in our pipeline (brown + orange in the screenshot), the build step is now longer which makes the overall pipeline close to the 1h which is the time-out limit we have in our current set-up.
image

@OxyFlax
Copy link
Contributor

OxyFlax commented Dec 9, 2024

Maybe to avoid building each time all the Sass files we could store somewhere the result or something to rebuild only the updated Sass files?
Or at least have a check that a Sass file was updated. I just got the same issue with a PR updating a single module.ts file, I'm not sure the check on the sass files was necessary in that case.

@kpanot
Copy link
Contributor

kpanot commented Dec 10, 2024

Thanks @OxyFlax , this is indeed a workaround to rely on Nx Cache or Lerna Change and trigger the extraction only when really needed.

@kpanot kpanot linked a pull request Dec 12, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants