Closed gobijan closed 2 years ago
Just chiming in for clarity: Rails now ship with the new pkg powered binary: https://tailwindcss.com/blog/standalone-cli. Rails and Phoenix are moving away from including npm scripts and bundling by default citing the default support for ES6 and http2 in-browser being good enough to provide unbundled code and "liberating" users by letting them choose the bundler of their choice if need be.
That being said, it just means that the plugin should be adapting "is_tailwind_installed" to check for the binary as fallback for not finding the node module. I would suggest to prioritize the node_module if it's found first, over the binary, in case someone installs the binary globally but is still working on a project with local node modules.
I'm will probably drop the is_allowed_to_start logic entirely https://github.com/sublimelsp/LSP-tailwindcss/blob/f8da7c5bbf457f54b70592416ee901c4ef24bd6c/plugin.py#L27
I left this comment a while ago, https://github.com/sublimelsp/LSP-tailwindcss/pull/30#issuecomment-995247891 For me it seems better to just let the server start and let the server decide if it can start in a workspace or not.
Yeah, I think that would remove useless complexity on your end and you could simply gracefully log a message in the console if you can't find any tailwind executables. I don't know how other people manage their LSP servers, but I enable most of mine globally since I work with the same stack very often so it makes sense. 🤷
This kind of method is there to guard against a modal dialog informing the user that the server won’t start. If the tailwindcss server doesn’t reply with an error to the initialize request then it’s okay to remove this check. If not, then you could expect new issues about this server not starting in web projects that are not set up for tailwind.
The selectors should probably also get extended to include text.html.ruby, text.html.rails, text.haml
Created a PR to fix this. If anyone of you can test this it would be nice. If not, I'll probably merge this sometime this week.
The selectors should probably also get extended to include text.html.ruby, text.html.rails, text.haml
I do not develop in ruby/rails, so I am not sure what syntax you need to have installed to have syntax highlighting in html files.
If you can create a PR for that, I would happily review it.
Adding this PR too it now works out of the box for Rails :) https://github.com/sublimelsp/LSP-tailwindcss/pull/36/files
Have it been tested to work? I just tried it out and it does not seem to work for me. I'm running Rails 7 with the standalone version of Tailwind and I do not get autocompletions in Rails related files (.html.erb
).
Actually got it working by adding a language id override for text.html.rails
to html
. I went into Preferences: LSP Language ID Mapping Overrides
and added the following:
{
"text.html.rails": "html"
}
What didn't seem to work however was going into Preferences: LSP-tailwindcss Settings
and setting tailwindCSS.includeLanguages
to the following:
{
"settings":
{
"tailwindCSS.includeLanguages": {
"rails": "html"
}
},
}
Not sure why. According to the tailwindcss-intellisense documentation it should be enough. I've attached the LSP debug output below.
As far as I can see by inspecting the vscode extension, the includeLanguages
is handled on the extension side and thus does absolutely nothing in ST. What might work is setting a "text.html.rails": "rails"
mapping and then passing option:
{
"initializationOptions": {
"userLanguages": {
"rails": "whatever"
}
},
}
Of course your solution should be fine too for this specific server if it doesn't care about languageId
(I don't think it would treat rails
and html
any different but I haven't studied its code very thoroughly so it might).
As far as I can see by inspecting the vscode extension, the includeLanguages is handled on the extension side and thus does absolutely nothing in ST.
Are you sure? I found the following reference to includeLanguages
from within the server itself.
These settings are also editable from within this package as can be seen my opening Preferences: LSP-tailwindcss Settings
. My thought were that these settings were listened to using the DidChangeConfiguration Notification event.
What might work is setting a "text.html.rails": "rails" mapping
This isn't necessary as the default rules will take the last part of any scope by default.
Are you sure? I found the following reference to
includeLanguages
from within the server itself.
That's the only reference which means that it's not really used anywhere.
This isn't necessary as the default rules will take the last part of any scope by default.
Right. So the alternative is to not touch the mapping but include the initializationOptions
I've posted.
Right. So the alternative is to not touch the mapping but include the initializationOptions I've posted.
Yes, I could do that as a "work around" for now. I think what I'm trying to convey (sorry, if I'm not being clear) is that we should probably support these settings. They don't seem to be specific to the VSCode extension. Settings are being read from a given source. The server asks for them via the Configuration Request. The client then notifies the server about changes using the DidChangeConfiguration Notification.
I believe what's lacking is some initial "glue code" in this package. We could read the settings before starting the server, and pass tailwindcss.includeLanguages
in the appropriate place in the initializationOptions
(userLanguages
in this case).
If the above doesn't make sense, I'd argue that we shouldn't really have these settings available at all. But given that they're defined, I believe the intention is that we can make use of them. Looking at the debug info I posted earlier as well, it looks like the settings are picked up correctly by the plugin as it is today, so it's just a matter of hooking them up.
Excerpt from the LSP communication
:: <-- LSP-tailwindcss workspace/configuration(3): {'items': [{'scopeUri': 'file:///Users/kevin/code/timetrail/app/views/layouts/application.html.erb', 'section': 'tailwindCSS'}]}
:: >>> LSP-tailwindcss 3: [{'rootFontSize': 16, 'emmetCompletions': False, 'colorDecorators': True, 'showPixelEquivalents': True, 'lint': {'invalidConfigPath': 'error', 'invalidVariant': 'error', 'cssConflict': 'warning', 'invalidApply': 'error', 'invalidTailwindDirective': 'error', 'invalidScreen': 'error', 'recommendedVariantOrder': 'warning'}, 'files': {'exclude': ['**/.git/**', '**/node_modules/**', '**/.hg/**']}, 'experimental': {'classRegex': []}, 'classAttributes': ['class', 'className', 'ngClass'], 'validate': True, 'includeLanguages': {'rails': 'html'}}]
I'd be happy to submit a pull request for it if we think it makes sense. 🙂
It would be easiest to add the initializationOptions.userLanguages
for all supported languageIds but ideally we would handle that through tailwindcss.includeLanguages
to match the original documentation.
Will just clarify that the server doesn't process tailwindcss.includeLanguages
at all nor does the DidChangeConfiguration
request needs to receive those. The VSCode extension logic just updates the languages
global and restarts the server from that handler so that the updated initializationOptions.userLanguages
can be send. The VSCode extension also uses tailwindcss.includeLanguages
to let VSCode know that it handles additional languages but that's VSCode-specific equivalent of our selector
.
Will just clarify that the server doesn't process tailwindcss.includeLanguages at all nor does the DidChangeConfiguration request needs to receive those. The VSCode extension logic just updates the languages global and restarts the server from that handler so that that updated initializationOptions.userLanguages can be send.
@rchl thanks for clarifying. 🙏 I went through the source code again and you're right. Given that, I think it makes sense to bootstrap the server with whatever you've provided in tailwind.includeLanguages
just for the sake of staying aligned with how it's done elsewhere.
However, I could also see us dropping tailwind.includedLanguages
altogether and default initializationOptions.userLanguages
to include whatever languages we do support (given our selector
) that currently does not match Tailwind default languages. For instance, we could map rails
to erb
.
However, I could also see us dropping tailwind.includedLanguages
That's usually how we deal with server settings that are actually handled in the (VScode) extension. But, whatever solution is fine by me.
@rwols yeah, perhaps that's the better option. In doing so, we could make a pass over the current settings and remove anything else that is VSCode extension specific. I guess that would be overall less confusing. There are still options that are worth keeping like tailwindCSS.experimental.classRegex
though. 🙂
However, I could also see us dropping tailwind.includedLanguages
That's usually how we deal with server settings that are actually handled in the (VScode) extension. But, whatever solution is fine by me.
The downside of that is that then we need to document our alternative rather than redirect to official documentation.
Hi I'm creating a new Rails project with
rails new example -c tailwind
This setup works without npm installed by providing the official tailwindcss executable that is standalone and puts a shim here:
~/.rbenv/shims/tailwindcss
However when I want to use the LSP now I can't because it says tailwind is not installed even though I clearly have access to it and it works in my rails project.
Is there a way to specify the tailwind executable or install the language server globally? How can this work with Rails?