-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Add @source inline(…)
#17147
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
Add @source inline(…)
#17147
Conversation
3b214e9
to
ff54c88
Compare
Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
IntelliSense counterpart of tailwindlabs/tailwindcss#17147
@philipp-spiess do we have some online docs for this ? |
This PR adds a new source detection feature: `@source not "…"`. It can be used to exclude files specifically from your source configuration without having to think about creating a rule that matches all but the requested file: ```css @import "tailwindcss"; @source not "../src/my-tailwind-js-plugin.js"; ``` While working on this feature, we noticed that there are multiple places with different heuristics we used to scan the file system. These are: - Auto source detection (so the default configuration or an `@source "./my-dir"`) - Custom sources ( e.g. `@source "./**/*.bin"` — these contain file extensions) - The code to detect updates on the file system Because of the different heuristics, we were able to construct failing cases (e.g. when you create a new file into `my-dir` that would be thrown out by auto-source detection, it'd would actually be scanned). We were also leaving a lot of performance on the table as the file system is traversed multiple times for certain problems. To resolve these issues, we're now unifying all of these systems into one `ignore` crate walker setup. We also implemented features like auto-source-detection and the `not` flag as additional _gitignore_ rules only, avoid the need for a lot of custom code needed to make decisions. High level, this is what happens after the now: - We collect all non-negative `@source` rules into a list of _roots_ (that is the source directory for this rule) and optional _globs_ (that is the actual rules for files in this file). For custom sources (i.e with a custom `glob`), we add an allowlist rule to the gitignore setup, so that we can be sure these files are always included. - For every negative `@source` rule, we create respective ignore rules. - Furthermore we have a custom filter that ensures files are only read if they have been changed since the last time they were read. So, consider the following setup: ```css /* packages/web/src/index.css */ @import "tailwindcss"; @source "../../lib/ui/**/*.bin"; @source not "../../lib/ui/expensive.bin"; ``` This creates a git ignore file that (simplified) looks like this: ```gitignore # Auto-source rules *.{exe,node,bin,…} *.{css,scss,sass,…} {node_modules,git}/ # Custom sources can overwrite auto-source rules !lib/ui/**/*.bin # Negative rules lib/ui/expensive.bin ``` We then use this information _on top of your existing `.gitignore` setup_ to resolve files (i.e so if your `.gitignore` contains rules e.g. `dist/` this line is going to be added _before_ any of the rules lined out in the example above. This allows negative rules to allow-list your `.gitignore` rules. To implement this, we're rely on the `ignore` crate but we had to make various changes, very specific, to it so we decided to fork the crate. All changes are prefixed with a `// CHANGED:` block but here are the most-important ones: - We added a way to add custom ignore rules that _extend_ (rather than overwrite) your existing `.gitignore` rules - We updated the order in which files are resolved and made it so that more-specific files can allow-list more generic ignore rules. - We resolved various issues related to adding more than one base path to the traversal and ensured it works consistent for Linux, macOS, and Windows. ## Behavioral changes 1. Any custom glob defined via `@source` now wins over your `.gitignore` file and the auto-content rules. - Resolves #16920 3. The `node_modules` and `.git` folders as well as the `.gitignore` file are now ignored by default (but can be overridden by an explicit `@source` rule). - Resolves #17318 - Resolves #15882 4. Source paths into ignored-by-default folders (like `node_modules`) now also win over your `.gitignore` configuration and auto-content rules. - Resolves #16669 5. Introduced `@source not "…"` to negate any previous rules. - Resolves #17058 6. Negative `content` rules in your legacy JavaScript configuration (e.g. `content: ['!./src']`) now work with v4. - Resolves #15943 7. The order of `@source` definitions matter now, because you can technically include or negate previous rules. This is similar to your `.gitingore` file. 9. Rebuilds in watch mode now take the `@source` configuration into account - Resolves #15684 ## Combining with other features Note that the `not` flag is also already compatible with [`@source inline(…)`](#17147) added in an earlier commit: ```css @import "tailwindcss"; @source not inline("container"); ``` ## Test plan - We added a bunch of oxide unit tests to ensure that the right files are scanned - We updated the existing integration tests with new `@source not "…"` specific examples and updated the existing tests to match the subtle behavior changes - We also added a new special tag `[ci-all]` that, when added to the description of a PR, causes the PR to run unit and integration tests on all operating systems. [ci-all] --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com>
Error: @source inline('{hover:,}bg-{slate,gray,zinc,neutral,stone,red,orange,amber,yellow,lime,green,emerald,teal,cyan,sky,blue,indigo,violet,purple,fuchsia,pink,rose}-{50,{100..900..100},950}'); |
@sudarshan-mane Sounds like you're on the wrong version! Make sure both |
Hi @philipp-spiess is this feature now supported in v4.1.1 ? I want to migrate but we need the safeList feature for going ahead, thanks |
@chrism1996 Yep it's in 4.1 👍 |
@philipp-spiess I have a question related to this source inline: I dont know if is possible to get the "bg-red" / "bg-yellow" without any value. Example:
In this case is generated With "light" and "dark" works, but if I pass a Example in Tailwind Play: https://play.tailwindcss.com/YCUsYk1Gmt?file=css Edit: I have it working like this in two lines... but can be better if we can send direct a pass a
Thanks. |
@daniel-perez-f The problem with the first pattern is that you're generating In the correct single line version you have to make sure that the @source inline('{hover:,focus:,}bg-{red,yellow}{,-{50,{100..900..100},950,light,dark}}'); I kinda like the two separate versions — feels more understandable — but you'll want to make sure you generate hover and focus versions as well if the intent is to match the pattern above it: @source inline('{hover:,focus:,}bg-{red,yellow}-{50,{100..900..100},950,light,dark}');
@source inline('{hover:,focus:,}bg-{red,yellow}'); |
This PR adds a new experimental feature that can be used to force-inline utilities based on an input string. The idea is that all utilities matching the source string will be included in your CSS:
Additionally, the source input is brace-expanded, meaning you can use one line to inline a whole namespace easily:
This feature is also compatible with the
not
keyword that we're about to add to@source "…"
in a follow-up PR. This can be used to set up an ignore list purely in CSS. The following code snippet, for example, will ensure that the.container
utility is never created:Test plan
braces
library: