-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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
Performance improvements + memory leak fix #3032
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3032 +/- ##
=======================================
Coverage 93.28% 93.28%
=======================================
Files 177 178 +1
Lines 1801 1831 +30
Branches 318 324 +6
=======================================
+ Hits 1680 1708 +28
- Misses 104 105 +1
- Partials 17 18 +1
Continue to review full report at Codecov.
|
1bf7ba4
to
6dc5fc2
Compare
…exists Otherwise we will generate the lookup tree.
1e2931f
to
a070e70
Compare
a070e70
to
5ece981
Compare
I've upgraded to v2.0.2 and I'm still running into heap memory crashes...
Is there anything I should have to change in my build process to take advantage of the fixes in this PR @RobinMalfait? |
@jalendport Hey! Can you create a reproduction case for this? Also are you sure that you are on the latest version? |
@RobinMalfait I'm seeing the same thing as @jalendport. Version of tailwind:
In my case, it's while I'm using Gatsby development mode. Underneath they're using webpack I believe. |
Here’s the error I’m getting, in case it’s helpful. Running
|
Can it be used in 1.9.x version, we need ie11 support |
Normally I wouldn't make a PR for a minor version upgrade, but the 2.0.2 version contains some important performance improvements. tailwindlabs/tailwindcss#3032
This PR will improve some of the performance issues people have seen. But even more importantly it also fixes a bad memory leak where if you use tailwindcss in a running process (like a webpack watch), it could happen that once in a while you get a "JavaScript heap out of memory" error and everything crashes. This has been fixed, and also improves a bit of performance.
Another issue that has been pointed out in #2544 and #2820 is that when you split up files, that you get an error that some utilities don't exist when using
@apply
. While splitting up is not a perfect solution, this PR will at least fix that issue.Let's go in a bit more detail here:
Broken
@apply
When you split up files (splitting up
@tailwind base;
,@tailwind utilities;
and@tailwind components;
), and one of your files contains something like this:Then we made the assumption that if we found a
@tailwind
rule, that we don't have to re-compute all the utilities so that you can apply them. However, in this case only thebase
is included in the full css. Therefore you will get an error thatbg-gray-100
could not be found.This PR fixes that, by looking if it contains a
@tailwind utilities;
rule. If it does, then we don't have to compute the all the utilities again because it already exists. If it doesn't exist then we will generate the tree so that you can apply those utilities.One of the main reasons for this is for example in Vue you can define css per component:
But it would be very annoying to write the following code in every single component:
Memory leak
We have an optimization in the codebase with
useMemo
(not this is not React, yes I used the same name 🙈) so that we can cache certain calculations if we already did a calculation for the same key. However, every time the config changes (in a running process) we start re-calculating things. For example, imagine that you enableddarkMode: 'class'
we have to make sure that we create new utilities for darkMode. However, if you remove darkMode again we didn't cleanup all those things.Long story short, in this PR we also make sure to clear all the caches when the config changes.
Why splitting up is not that ideal, however, it's fast with webpack
In development the css output file of Tailwind can be easily
+3 MB
. Just to be clear, this is NOT an issue in production, purging is amazing! https://tailwindcss.com/docs/optimizing-for-production.The main reason for this is the
@tailwind utilities;
being huge.Some people started splitting up each part of
@tailwind ...
in separate chunks. This works, because@tailwind utilities;
won't change as long as the config file doesn't change. This means that webpack can cache this file perfectly. When you have a separate file for your css, webpack only has to worry about that part.However there is a catch...
In Tailwind we have the concept of
@layer
's (https://tailwindcss.com/docs/functions-and-directives#layer). This means that when you use something like:This means that we need a single css file so that we can insert custom css in the correct spot.
This won't work anymore once you start splitting up each
@tailwind
at rule in separate files, because now everything is separated. This can lead to incorrect behaviour and specificity because the order matters.Fixes: #2986, #3024, #2544 and #2820