Remove layer(utilities) if imports contain @utility
#14738
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We have a migration that adds the `layer(…)` next to the `@import` depending on the order of original values. For example: ```css @import "tailwindcss/utilities": @import "./foo.css": @import "tailwindcss/components": ``` Will be turned into: ```css @import "tailwindcss": @import "./foo.css" layer(utilities): ``` Because it used to exist between `utilities` and `components`. Without this it would be _after_ `components`. This results in an issue if an import has (deeply) nested `@utility` at-rules after migrations. This is because if this is generated: ```css /* ./src/index.css */ @import "tailwindcss"; @import "./foo.css" layer(utilities); /* ./src/foo.css */ @Utility foo { color: red; } ``` Once we interpret this (and thus flatten it), the final CSS would look like: ```css @layer utilities { @Utility foo { color: red; } } ``` This means that `@utility` is not top-level and an error would occur. This fixes that by removing the `layer(…)` from the import if the imported file (or any of its children) contains an `@utility`. This is to ensure that once everything is imported and flattened, that all `@utility` at-rules are top-level.
|
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @RobinMalfait and the rest of your teammates on |
| } | ||
| } | ||
|
|
||
| return { convertablePaths, nonConvertablePaths } | ||
| return { convertiblePaths, nonConvertiblePaths } |
There was a problem hiding this comment.
To be fair, convertable makes more sense to my non-native-English brain lol
There was a problem hiding this comment.
I mean same — it does make more sense. I guess I just wasn't thinking when I wrote it originally haha
| if (!Array.from(sheet.importRules).some((node) => node.raws.tailwind_injected_layer)) { | ||
| continue | ||
| } | ||
|
|
There was a problem hiding this comment.
I think you can also skip stylesheets with parent stylesheets yeah?
There was a problem hiding this comment.
Ah wait not if the tailwind stuff is in a non-root stylesheet so maybe not.
thecrypticace
approved these changes
Oct 21, 2024
RobinMalfait
deleted the
robin/remove_layer_utilities_if_imports_contain_utility_
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We have a migration that adds the
layer(…)next to the@importdepending on the order of original values. For example:Will be turned into:
Because it used to exist between
utilitiesandcomponents. Without this it would be aftercomponents.This results in an issue if an import has (deeply) nested
@utilityat-rules after migrations. This is because if this is generated:Once we interpret this (and thus flatten it), the final CSS would look like:
This means that
@utilityis not top-level and an error would occur.This fixes that by removing the
layer(…)from the import if the imported file (or any of its children) contains an@utility. This is to ensure that once everything is imported and flattened, that all@utilityat-rules are top-level.