Will @content support require updates to the vscode extension?

[tylersayshi]

RE: #14078

Seeing this change for different css driven tailwind configurations shows how we could draw clearer lines between separate tailwind configs.

@adamwathan gave a good example for handling node libraries that use tailwind: https://x.com/adamwathan/status/1819427336502047227

I am interested in taking advantage of this for using multiple configurations in a single project. This is because my team has a tailwind config that overrides the colors and spacing configuration, but we want to progressively move over to the default tailwind config.

I think given the new @content directive it would be trivial to pair this with the @config directive to have the styles build correctly, without needing to deal with prefixes.

My question though: Will the ide extensions be updated to detect the correct tailwind config based off the current file's slug?

PS I would have posted this on the intellisense repo, but there is no discussion board there haha

[philipp-spiess]

Hey @tylerlaws0n! Absolutely, the VS Code extension needs to update to handle the new directive (in fact I've started to think about this this week).

However, as you already hinted, there are some complexities around multiple configurations. Specifically we will need some heuristics to figure out which tailwind project a specific source files belongs to since one source file could be part of different builds/config.

In your example, how would these globs look like? Are they mutually exclusive (so files from config A do not match files from config B and vice versa)?

[tylersayshi]

Yeah, definitely mutually exclusive. I shutter to think about what would happen if configs overlapped in file matches.

For the use I am thinking of it would look something like this:

Config A: src/old-components/**/*.tsx
Config B: src/new-components/**/*.tsx

There are many more ways to slice this up and make them mutually exclusive, but It would make sense to me if tailwind made the decision to not support overlapping content files for configs. Or at least threw a warning or something? This should make implementing the extension support much easier while also reducing unexpected behavior for developers.

[philipp-spiess]

@tylerlaws0n Yeah we're still thinking this through either. Your use case seems reasonable but it also means that you would probably want an option to disable the automatic content loading (because both pats otherwise will be part of the automatic content 🤔). What's making this a bit complex is that technically any valid Tailwind config .css file can be used at any directory in the project (e.g. you could have foo/bar/style.css and load it from the root). I think as far as the VS Code extension is concerned, we can probably rely on some heuristics to find out the best possible context.