Skip to content

fix(tailwindcss): only attach to existing files #3875

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

Closed
wants to merge 1 commit into from

Conversation

igorlfs
Copy link
Contributor

@igorlfs igorlfs commented May 27, 2025

The tailwind LSP behaves poorly when attaching to "virtual" buffers. I've noticed that it gets stuck with 100% CPU usage when using the "virtual buffers" from diffview (i.e., via :DiffviewOpen).

I thought about reporting this issue upstream (tailwind), but I decided to first open a PR here to get some thoughts. There's a related issue on neovim, and I understand that the current method to handle conditional attaching is using the root_dir function, but so far I haven't seen any configs using this trick, so I'm not sure if it's welcome here.

@justinmk
Copy link
Member

should this config specify requires_workspace=true ?

the current method to handle conditional attaching is using the root_dir function, but so far I haven't seen any configs using this trick, so I'm not sure if it's welcome here.

root_dir is used in some configs here, afair.

root_files = util.insert_package_json(root_files, 'tailwindcss', fname)
root_files = util.root_markers_with_field(root_files, { 'mix.lock' }, 'tailwind', fname)
on_dir(vim.fs.dirname(vim.fs.find(root_files, { path = fname, upward = true })[1]))
if vim.uv.fs_stat(fname) ~= nil then
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you add a 1-line comment giving a hint

Suggested change
if vim.uv.fs_stat(fname) ~= nil then
-- tailwind lsp behaves poorly if the buffer is not backed by a file. https://github.com/neovim/nvim-lspconfig/pull/3875
if vim.uv.fs_stat(fname) ~= nil then

@igorlfs
Copy link
Contributor Author

igorlfs commented Jun 2, 2025

Looks like it will be fixed on the server side, so no need for a workaround here

@igorlfs igorlfs closed this Jun 2, 2025
@justinmk
Copy link
Member

justinmk commented Jun 3, 2025

Thanks for followup!

@igorlfs igorlfs deleted the fix/tailwind-attach branch June 3, 2025 11:03
@thecrypticace
Copy link

thecrypticace commented Jun 3, 2025

o/ I'm a maintainer of the Tailwind CSS language server. I just did some research into this and the thing I thought was happening is not. It did reveal a bug that causes the exact saome issue but I think Neovim is at fault here as well. When you open file at foo://index.html Neovim will cause the server to be initialized with a workspace folder URI of file://. which resolves to the root directory (/ on *nix and \\ on Windows).

Can see more details in my comment here: tailwindlabs/tailwindcss-intellisense#1396 (comment)

I think detecting a workspace folder of / is a reasonable way to work around this issue. I think I'm going to warn + ignore the workspace folder in this case. I could also basically "crash" the server by throwing an error causing it to exit. Do you have any thoughts on what I should do here?

@justinmk
Copy link
Member

justinmk commented Jun 4, 2025

When you open file at foo://index.html Neovim will cause the server to be initialized with a workspace folder URI of file://. which resolves to the root directory (/ on *nix and \\ on Windows).

What is the lsp client expected to do in that case (arbitrary non-file scheme)? If you feel like opening an issue in core https://github.com/neovim/neovim that will be helpful, I didn't find a tracking issue for this topic.

Related: neovim/neovim#19797

@igorlfs
Copy link
Contributor Author

igorlfs commented Jun 4, 2025

Hey Justin, I tracked down the root cause of this issue and nvim actually handles these schemes just fine. The issue arises from using vim.fs.root to define the root_dir, see this comment. Basically, with non-file buffers, the behavior of falling back to neovim's cwd returns a relative path (in this case .; which is why we see the folder URI as file://.) instead of an absolute path. If using vim.fs.find, the absolute path is returned and there's no issue with these buffers.

I can open an issue to track that, if you see fit.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants