Add support for @source
#1030
Add support for @source
#1030
Conversation
philipp-spiess
force-pushed
the
feat/at-plugin-at-source
branch
from
ef3c51b to
7eab19f
Compare
philipp-spiess
changed the title
@plugin and @source@plugin and @content
philipp-spiess
changed the title
@plugin and @content@plugin and @source
philipp-spiess
force-pushed
the
feat/at-plugin-at-source
branch
from
a75348c to
446e6be
Compare
philipp-spiess
changed the title
@plugin and @source@source
philipp-spiess
force-pushed
the
feat/at-plugin-at-source
branch
from
e1a28b2 to
52e7930
Compare
packages/tailwindcss-language-server/src/resolve-css-imports.ts
Outdated
Show resolved
Hide resolved
packages/tailwindcss-language-server/src/resolve-css-imports.ts
Outdated
Show resolved
Hide resolved
The ESM version of Oxide has never had a default export
| try { | ||
| resultV2 = oxide.scanDir({ | ||
| base: options.basePath, | ||
| sources: options.sources, | ||
| }) | ||
| } catch { | ||
| resultV1 = oxide.scanDir({ | ||
| base: options.basePath, | ||
| globs: true, | ||
| }) | ||
| } |
There was a problem hiding this comment.
This raises the questions:
- Should we properly version this API?
- When can we deprecate support for an alpha release version? Should we even support older alpha releases? I worry that if we don't define a supported range right now, this will creep and become an unnecessary burden over time.
Maybe we can say all alphas are supported for now but once we release something more stable, we'll drop support for it and will expect our users to upgrade? WDYT?
There was a problem hiding this comment.
Since we have the load path, maybe we could read the package.json file to see what version we are working with 🤔
There was a problem hiding this comment.
-
Should we properly version this API?
Well… we can't do that exactly because it's already released so… -
When can we deprecate support for an alpha release version?
Good question — I think maybe once we're closer to a more stable API + a month or so we can drop stuff then.
Since we have the load path, maybe we could read the package.json file to see what version we are working with
Yeah that is an option 🤔
|
Thanks for fixing this up @thecrypticace. Seems like this is good to go for now but I left a question regarding oxide version support. I can't stamp my own PR so if you would do the honor :) |
Fixes: #1033 Fixes: #1034 Fixes: #1035 Fixes: #1036 Fixes: #1037 Fixes: #1038 Fixes: #1039 Fixes: #1040 Fixes: #1041 Fixes: #1042 Fixes: tailwindlabs/tailwindcss#14274 When we worked on #1030, we added a new `postcss` run inside the project locator. Unfortunately this can crash (e.g. when non standard CSS features are discovered like those in a `.sass` or `.scss` file) which currently breaks the whole project locator step, making the extension not work anymore as soon as such a file is detected. The short term fix here is to handle this error. In the very future we have to replace this postcss step anyways because now that Tailwind v4 supports plugins and JS config files, we need to be able to execute the config to get the proper sources. ## Before <img width="659" alt="before" src="https://github.com/user-attachments/assets/8f86e70d-66c2-40a1-ba97-9f4b9b018c94"> ## After <img width="656" alt="after" src="https://github.com/user-attachments/assets/bfd17b72-c748-4ea9-b73d-86c444cda16a">
This PR does multiple things:
@pluginand@sourcedirective in the CSS language.@sourcerules and respect them similarly how we handled custom content paths in V3.For detecting the right content, we load the Oxide API installed in the user's Tailwind project. To do this in a backward compatible way, we now also load the
package.jsonfile of the installed Oxide version and support previous alpha releases for a limited amount of time.