You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Compute correct document selectors when a project is initialized (#1335)
Fixes#1302
Possibly helps #1322
Possibly helps #1323
This PR fixes a problem where files may fail to match against the
appropriate project in a given workspace — and in some cases this
behavior could be "fixed" by opening multiple files until all projects
in a workspace had their selectors recomputed. (A selector is a file
pattern/path paired with a "priority" that tells us how files match
different projects in a workspace)
The problem here is caused by a few things:
- We fixed a bug where auto source detection in v4 silently failed in
IntelliSense. After fixing this a file could get matched against one of
the globs or file paths detected by Oxide.
- A workspace with lots of CSS files may end up creating more than one
"project"
- Upon project initialization we would recompute these selectors **based
on the resolved JS config** (necessary for v3 projects because we
compile ESM or TS configs during intiialization and not discovery).
Obviously, v4 projects do not have JS configs (even if you're using
`@config` or `@plugin` it's not actually the config file we care about.
It's the design system created from the CSS file that matters.) so we
were then throwing away these document selectors.
In a workspace with multiple detected projects (could be because of
multiple CSS "roots", some v3 and some v4 files, etc…) we would check
the file against the selectors of each project, pick out the most
specific match, then initialize the project. The problem is that, when
we re-computed these selectors during initialization they changed. This
has the side effect of dropping the patterns that we picked up from
Oxide for a v4 project.
This would then cause any subsequent requests for a file to match a
*different* project. So for example, a request to compute the document
colors would cause a project to be matched then initialized. Then a
hover in the same file would end up matching a completely different
project.
This PR addresses this by doing two things:
1. Using the same codepath for computing a projects document selectors
during discovery and initalization
2. Normalize Windows drive letters in source paths picked up by Oxide.
This would have the effect of some content paths not matching a project
when it otherwise should on Windows.
In the future it'd probably be a good idea to make documents "sticky"
while they are open such that an open document picks a project and
"sticks" to it. We'd still want to recompute this stickiness if the
config a file is attached to changed but this is a future task as there
might be side effects from doing this.
Copy file name to clipboardExpand all lines: packages/vscode-tailwindcss/CHANGELOG.md
+2
Original file line number
Diff line number
Diff line change
@@ -13,6 +13,8 @@
13
13
- Handle helper function lookups in nested parens ([#1354](https://github.com/tailwindlabs/tailwindcss-intellisense/pull/1354))
14
14
- Hide `@property` declarations from completion details ([#1356](https://github.com/tailwindlabs/tailwindcss-intellisense/pull/1356))
15
15
- Hide variant-provided declarations from completion details for a utility ([#1356](https://github.com/tailwindlabs/tailwindcss-intellisense/pull/1356))
16
+
- Compute correct document selectors when a project is initialized ([#1335](https://github.com/tailwindlabs/tailwindcss-intellisense/pull/1335))
17
+
- Fix matching of some content file paths on Windows ([#1335](https://github.com/tailwindlabs/tailwindcss-intellisense/pull/1335))
0 commit comments