-
Notifications
You must be signed in to change notification settings - Fork 168
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
VSCode: ERB file false positive problems #2282
Comments
Thank you for the bug report! For the time being, downgrading the extension to v0.7.10 should bring back the old behaviour - since it does not register the extension for handling ERB files. Are you positive the issue is with solargraph being in the Gemfile, though? The Ruby LSP is its own independent Ruby process and we don't require solargraph, so I can't immediately see how it being in the Gemfile would impact ERB functionality. |
@vinistock, downgrading the extension to |
FWIW, I am having this same problem, and my project does not use solargraph. |
@vinistock Solargraph being in the |
With the current extension version, in the VS Code footer at the bottom right, is it showing |
@andyw8 For me it shows as |
We don't even show diagnostics for ERB files (we return early). I think this is what's happening: we define erb as the language ID with our grammar file associated to it. Any a file doesn't match the I believe that can only happen if another extension or your VS Code settings are associating a different language ID to ERB files. Do any of you have any other Ruby VS Code extensions or the following setting? {
// Your JSON settings
"files.associations": {
// If you switch the language ID of ERB files to another one, there will be a mismatch
// in the server
"*.erb": "Ruby ERB"
}
} |
Found this issue after running into the same issue with erb file. Reverting to an older version worked. The file is listed as settings{
"[javascript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[markdown]": {
"editor.defaultFormatter": "esbenp.prettier-vscode",
"editor.formatOnSave": true
},
"[yaml]": {},
"deno.enable": false,
"workbench.startupEditor": "newUntitledFile",
"files.trimTrailingWhitespace": true,
"editor.tabSize": 2,
"files.insertFinalNewline": true,
"extensions.ignoreRecommendations": false,
"gitlens.currentLine.enabled": false,
"gitlens.hovers.currentLine.over": "line",
"gitlens.codeLens.enabled": false,
"editor.rulers": [80, 120],
"terraform.indexing": {
"enabled": false,
"liveIndexing": false,
"delay": 500,
"exclude": [".terraform/**/*", "**/.terraform/**/*"]
},
"gitlens.advanced.messages": {
"suppressLineUncommittedWarning": true
},
"[rust]": {
"editor.defaultFormatter": "matklad.rust-analyzer"
},
"editor.formatOnSave": true,
"editor.renderWhitespace": "boundary",
"rust-client.disableRustup": true,
"search.useGlobalIgnoreFiles": true,
"[json]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"javascript.updateImportsOnFileMove.enabled": "always",
"rust-analyzer.diagnostics.disabled": ["missing-unsafe"],
"[javascriptreact]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[jsonc]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"workbench.editorAssociations": {
"*.ipynb": "jupyter.notebook.ipynb"
},
"[sql]": {
"editor.defaultFormatter": "adpyke.vscode-sql-formatter"
},
"window.restoreWindows": "none",
"[nix]": {
"editor.defaultFormatter": "jnoortheen.nix-ide"
},
"nix.serverPath": "nil",
"files.associations": {
"COMMIT_EDITMSG": "git-commit"
},
"[typescript]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[html]": {
"editor.defaultFormatter": "vscode.html-language-features"
},
"files.maxMemoryForLargeFilesMB": 8192,
"terraform.languageServer.enable": true,
"redhat.telemetry.enabled": false,
"nix.serverSettings": {},
"workbench.editor.empty.hint": "hidden",
"[typescriptreact]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"rubyLsp.rubyVersionManager": {
"identifier": "none"
},
"window.zoomLevel": 1,
"git.enableCommitSigning": true,
"rubyLsp.enableExperimentalFeatures": true,
"[css]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
},
"[scss]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
}
} |
@vinistock I did have Edit: In the VSCode developer tools 'element' view, the editor instance data-mode-id is set properly to |
If you turn on verbose tracing for the server: // Settings.json
{
"ruby lsp.trace.server": "verbose"
} All requests and their parameters get printed to the If that's not the case, something is changing the language ID of ERB files. It could be a user setting, a workspace setting (.vscode/setings.json), a different extension. We need to understand what is changing the language ID. |
@vinistock Got the trace (after a scary amount of output):
|
@vinistock If it helps, here is the full output when opening a simple file:
|
So, the language ID is correct. Oh, maybe the server is outdated? If you do
Does that fix the issue? |
@vinistock I ran that server gem update VSCode command, but that didn't fix the issue either, unfortunately. |
If you click on the language status item (the |
Okay. That makes sense, the server isn't able to handle ERB files. Usually, when it fails to upgrade, it's because your project is locked to an older version of You can try it on the terminal with BUNDLE_GEMFILE=.ruby-lsp/Gemfile bundle update ruby-lsp |
humm, |
It could be the |
Updating the server fixed it for me; thanks for the fast responses. In case it's not a pain to implement, detecting a minimum server version with the extension would be have been a better error to encounter than the parsing output. |
@LucasKuhn that won't work in the long term. The next time you upgrade any gem in the application, the Ruby LSP will overwrite the custom lockfile again and you'll end up in the same scenario again. Check if |
Thank you @vinistock! Deleted my suggestion to avoid confusion. |
solargraph is currently pinned to |
Ran into this issue tonight,I noticed I still had an old version of solargraph listed in my development group despite not using that extension anymore:
Removing this gem worked -- not a great solution if you use solargraph but if you don't and have the gem just remove it to resolve the issue. |
Removing |
Thanks for suggestion @vinistock Downgrading to |
What are your reasons for keeping solargraph around still? With https://gist.github.com/castwide/28b349566a223dfb439a337aea29713e and the |
FWIW, my problem was that I'm getting ruby-lsp via the ruby-lsp-rails gem (ruby-lsp-rails is the only thing my Gemfile), so trying to |
@hayesr you don't need ruby-lsp-rails in your Gemfile any more, ruby-lsp will automatically enable it when it detects a Rails app. Removing it should help with keeping things up-to-date. |
@andyw8 Ok that's helpful, thanks! |
@nikasvan I don't believe downgrading is an optimal solution. I suggested that while we were still understanding the issue. But it goes beyond not having errors for ERB files. If you are unable to upgrade the server gem, you will not have access to any new features we ship. Almost all features in a language server are implemented in the server and not on the client side. For example, if you can't upgrade past v0.17.2, you are currently missing out on:
Plus whatever we ship in the next versions until the constraint is lifted and you can successfully upgrade the Even if we came up with a way to avoid the errors for ERB, being unable to upgrade the language server gem is incompatible with delivering a good developer experience. We need to be able to get new features into the hands of developers. Bugfixes. Performance improvements. And the quicker we can do that, the better. |
Thanks for digging into this @vinistock and everybody else. For our project, it's another gem |
I was having the same issue and, after reading this issue start to finish, these were the steps:
This solved the ERB issue and the code navigation kept working! Thanks a lot for the work on this great DX tool. |
I created a proposal of a possible way to mitigate the issue #2311. At the root of the problem is the fact that some users cannot update the server gem, which means pushing a fix in the server is useless (they wouldn't be able to upgrade to the version with the bug fix anyway). However, trying to fix this from the extension side isn't trivial either. The document selector, which dictates the file types handled by the language server, has to be informed as part of the client options before trying to spawn the language server. But it's not possible to know which version of the server gem will be installed for a project without first trying to boot it (there's no way to know which version Bundler will resolve to before we actually launch). Mutating the document selector after boot has no effect whatsoever. After the client has been launched with one document selector, it will continue to serve requests for all of the included file types. This means that the only possible workaround is to perform a full restart of the client if we identify that it does not have support for handling ERB files. Anyone running an old server version would need to launch the server twice every single time (which means running indexing twice as well), until they are able to upgrade the gem. Alternatively, we could also just print a warning linking to this issue and explaining what's wrong, but not automatically restart the client - but then the ERB issues will not go away. Frankly, none of the options are great and it kind of circles back to my previous point: there's no way to deliver a good developer experience if people can't use the latest versions of the server. |
This seems preferable to me, since it gives more of an opportunity to explain the problem to users. |
I really disliked the double-launch approach, so we ended up providing the ability to disable ERB support through a setting #2311. For users who find this issue in the future:I'm having trouble with ERB filesThe reason is because another dependency's constraints are blocking updates for the Not being able to upgrade the language server is troublesome and the optimal solution is to figure out why the upgrades are failing and then fix it. Read the rest of the issue for more context. How to avoid the issues temporarilyTurn off ERB support until you are able to upgrade the // Your VS Code settings
{
"rubyLsp.erbSupport": false
} Note: this setting is a temporary escape hatch. We will not support old versions of the language server indefinitely. After a few months of allowing users to turn off ERB support, we will remove the setting and go back to turning on support for all users. |
Updated to the latest version and added |
We haven't cut a release that includes the PR adding the setting yet. |
That solves it to me |
I removed |
|
Updating |
I had the same issue. Removed rufo & solargraph from Gemfile, bundle install. Problem solved, thanks for hints |
Yes, that was all I needed to do. I didn't have |
Description
Description
The latest Ruby LSP VSCode extension (v0.7.11) generates numerous code problems for ERB files which should not be indicated as problems. The issue does not occur with v0.7.10. I've attached two screenshots - one of the code:
and another of the 'Problems' output:
I think I narrowed it down to it only occurring when the
solargraph
gem is installed from myGemfile
, but the odd behavior occurs whether the VSCode "castwide.solargraph" extension is enabled or not (even occurs with thesolargraph
gem present when the "castwide.solargraph" extension has been fully uninstalled).To Reproduce
.ruby-version
containing an rbenv ruby version (3.2.2 in my case)Gemfile
containing onlygem "solargraph", require: false
test.html.erb
file with any valid HTMLbundle install
and then open VSCode in that directorytest.html.erb
file once the LSP extension starts the language serverThe text was updated successfully, but these errors were encountered: