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
What build tool (or framework if it abstracts the build tool) are you using?
nx@19.7.2 monorepo with angular@18.2.4 apps and libs, with esbuild
What version of Node.js are you using?
v20.17.0
What browser are you using?
Chrome
What operating system are you using?
Windows
Reproduction URL
I tried to make a reproduction link but due to the source of the problem, making a reproduction link is tedious. There would be the need to make many libs, with many components.
If the description of the issues doesn't give satisfaction, i will try again to make scripts to make a repo big enough
nx automatically creates patterns with createGlobPatternsForDependencies (finds all libs to be included in tailwind compilation)
in our project, that may mean 150 libs, times two since we parse .ts and .html files, so 300 paths.
when tailwind check for the presence of a broad pattern for each file, if the path match with any paths, resulting in great amount of checks.
When compiling prior to this version or comment the feature, we compile in ~90 seconds with the check, it takes ~180 seconds.
When removing the use of createGlobPatternsForDependencies and switching to a wider pattern, we still get ~105 seconds and could be considered a loss (we would be generating the same big CSS file for each of or application, regardless of what it actually needs)
When upgrading to the 3.4.13 version where an optimization was implemented, we get ~120 seconds, witch is still quite long.
PS: i should add that tailwind being recompiled on serve, the X seconds increase of compilation times makes live development that much more painful, transforming a few needed seconds into a minute of waiting, maybe more.
Could there be an option to remove this check entirely for thoses who are sure of their patterns and look for performance ?
The text was updated successfully, but these errors were encountered:
The-io-dev
changed the title
BroadPattern check is still quite ressource hungry
BroadPattern check is still quite resource hungry
Oct 8, 2024
The-io-dev
changed the title
BroadPattern check is still quite resource hungry
BroadPattern check drastically increase the compilation time of large projects
Oct 22, 2024
What version of Tailwind CSS are you using?
3.4.8
What build tool (or framework if it abstracts the build tool) are you using?
nx@19.7.2 monorepo with angular@18.2.4 apps and libs, with esbuild
What version of Node.js are you using?
v20.17.0
What browser are you using?
Chrome
What operating system are you using?
Windows
Reproduction URL
I tried to make a reproduction link but due to the source of the problem, making a reproduction link is tedious. There would be the need to make many libs, with many components.
If the description of the issues doesn't give satisfaction, i will try again to make scripts to make a repo big enough
Describe your issue
The issues comes from this PR #14140.
What happens is :
createGlobPatternsForDependencies
(finds all libs to be included in tailwind compilation).ts
and.html
files, so 300 paths.When compiling prior to this version or comment the feature, we compile in ~90 seconds with the check, it takes ~180 seconds.
When removing the use of
createGlobPatternsForDependencies
and switching to a wider pattern, we still get ~105 seconds and could be considered a loss (we would be generating the same big CSS file for each of or application, regardless of what it actually needs)When upgrading to the 3.4.13 version where an optimization was implemented, we get ~120 seconds, witch is still quite long.
PS: i should add that tailwind being recompiled on serve, the X seconds increase of compilation times makes live development that much more painful, transforming a few needed seconds into a minute of waiting, maybe more.
Could there be an option to remove this check entirely for thoses who are sure of their patterns and look for performance ?
The text was updated successfully, but these errors were encountered: