Same app, same components, upgraded from v3 to v4 and the emitted stylesheet more than quadrupled. Nothing about the UI changed.
I have read the output and there are thousands of utilities in there that no component of mine uses. Some of them are arbitrary values with hex colours I have never typed. I do not have a content array to look at any more, so I do not know where to start narrowing this down.
Check whether the 188kb is before or after compression, because utility CSS compresses absurdly well - it is thousands of near-identical short rules. 188kb raw is frequently under 20kb over the wire, and if that is the case you may be optimising a number that no user experiences.
True and still worth fixing. Compression is on the transfer, the parse is on the device, and 188kb of CSS to parse on a mid-range Android is not free. Worth checking before panicking, not worth ignoring afterwards.
Do the boring diff. Pull the selectors out of both stylesheets, sort them, and diff the two lists. It is almost never spread evenly - it is one family with a thousand members and once you see the name you immediately know which file it came from.
When I did this it was around 4,000 text-[#...] utilities generated from a colour picker component that had every hex value in a plain string array in the same file. The scanner cannot tell a colour list from intent.
v4 emits the whole utility set now, that is the design change. The size is expected and you cannot tree-shake it.
No, v4 still only generates what it has seen in a source file. What changed is how it decides which files to look at, which is exactly why this thread exists. If it emitted everything, the number would be the same for everybody and it very much is not.
Also confirm the file you are measuring is the one being served. I spent a while on a similar jump and it was a stale asset from a previous build still sitting in the output directory and being picked up by the manifest, so I was measuring a file nothing linked to.
Confirm the old v3 build step is actually gone from your pipeline. I shipped both stylesheets for two weeks and spent one of them trying to explain a size regression that was just addition.
@burr_bennet · last mo. · 2 replies
v4 detects sources automatically from the stylesheet's project root and respects
.gitignore. Two ways that goes wrong:One, your build output directory is not actually gitignored, or you added an explicit
@sourcethat reaches it. Now it scans your previous build, and every class string that has ever existed in that project comes back from the dead. This is the common one and it explains "hex colours I never typed", because they were in a build from four months ago.Two, some directory of content - markdown, JSON fixtures, a vendored file - contains words that happen to parse as candidate utilities.
Fix is to stop relying on detection. Narrow it with explicit
@sourcerules for the directories you actually author in, and carve out the offender with a@source notrule. Then diff the output again and it should drop back.Reply
Report
@lowell_frame · last mo.
Check your exact v4 minor before you write
@source not, it was not there from the first release. If it parses as an error that is what happened and you have not typed it wrong.Reply
Report