Skip to content

Tailwind CSS LSP Not Working in Cloned Laravel Project #1322

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.

Sign up for GitHub

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

Jump to bottom
Open
end3r-man opened this issue Apr 18, 2025 · 11 comments
Open

Tailwind CSS LSP Not Working in Cloned Laravel Project #1322

end3r-man opened this issue Apr 18, 2025 · 11 comments

Comments

@end3r-man
Copy link

What version of VS Code are you using?

Im using neovim

What version of Tailwind CSS IntelliSense are you using?

v0.14.15

What version of Tailwind CSS are you using?

v4.1.4

What package manager are you using?

npm

What operating system are you using?

linux

Tailwind config

@import url('https://fonts.googleapis.com/css2?family=Manrope:[email protected]&display=swap');
@import "tailwindcss";

@plugin "@iconify/tailwind4";
@plugin "daisyui" {
  themes: light --default;
}

@source "../views";
@source "../views/**/*.blade.php";
@source '../../vendor/laravel/framework/src/Illuminate/Pagination/resources/views/*.blade.php';
@source '../../storage/framework/views/*.php';
@source '../**/*.blade.php';
@source '../**/*.js';

@theme {
    --font-sans: 'Instrument Sans', ui-sans-serif, system-ui, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji',
        'Segoe UI Symbol', 'Noto Color Emoji';
}

Nvim Code settings

			tailwindcss = {
				filetypes = {
					"html",
					"blade",
					"javascript",
					"typescript",
					"vue",
					"javascriptreact",
					"typescriptreact",
				},
			},

Describe your issue

i'm encountering an issue with the Tailwind CSS Language Server Protocol (LSP) in my Laravel project. Here's a breakdown of the problem:

Issue Description:

When I create a new Laravel project with Tailwind CSS v4, the Tailwind CSS LSP works perfectly. I can get autocompletion without any issues.

However, when I clone an existing Laravel project from a Git repository that also uses Tailwind CSS v4, the Tailwind CSS LSP stops working. I don't get any autocompletion suggestions.
@thecrypticace
Copy link
Contributor

If it works in a new project but does not in a cloned project the difference is related to the content / files in the cloned project.

Is it possible to provide the project?

@end3r-man
Copy link
Author

If it works in a new project but does not in a cloned project the difference is related to the content / files in the cloned project.

Is it possible to provide the project?

ill share a example repo

@end3r-man
Copy link
Author

https://github.com/end3r-man/tailwind-test

@thecrypticace
Copy link
Contributor

thecrypticace commented Apr 22, 2025 •
edited
Loading

fwiw this project works fine in Zed (using our language server) and in VSCode. This is possibly the same issue as #1323 since they're having issues with Neovim and our language server as well.

I'm not sure what that issue is. Is it possible for you to show logs produced by the language server (window/logMessage calls from the protocol) in your nevoim setup?

@thecrypticace
Copy link
Contributor

Oh something that also would be helpful is knowing what Node.js version you're on

@end3r-man
Copy link
Author

Oh something that also would be helpful is knowing what Node.js version you're on

node v23.9.0

@thecrypticace thecrypticace mentioned this issue Apr 24, 2025
Merged
@end3r-man
Copy link
Author

fwiw this project works fine in Zed (using our language server) and in VSCode. This is possibly the same issue as #1323 since they're having issues with Neovim and our language server as well.

I'm not sure what that issue is. Is it possible for you to show logs produced by the language server (window/logMessage calls from the protocol) in your nevoim setup?

i tried in vscode and nvim it doesnt work

@end3r-man
Copy link
Author

Oh something that also would be helpful is knowing what Node.js version you're on

v23.9.0

@end3r-man
Copy link
Author

any solution ??

@thecrypticace
Copy link
Contributor

thecrypticace commented May 12, 2025 •
edited
Loading

Ah sorry. This is likely related to #1335 but I'm not 100% sure. Since this doesn't work in VSCode either can you please provide the logs from "Tailwind CSS: Show Output" in the command palette (after opening a file and verifying that it doesn't work)?

@end3r-man
Copy link
Author

Ah sorry. This is likely related to #1335 but I'm not 100% sure. Since this doesn't work in VSCode either can you please provide the logs from "Tailwind CSS: Show Output" in the command palette (after opening a file and verifying that it doesn't work)?

ok ill share it

thecrypticace added a commit that referenced this issue May 14, 2025
@thecrypticace
Compute correct document selectors when a project is initialized (#1335)
ab0bef5 
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@thecrypticace @end3r-man