This PR introduces the support for `textDocument/diagnostics`. This will be preferred over the other way around `textDocument/publishDiagnostics`
It is a newer concept between language server and the clients (editors).
> Diagnostics are currently published by the server to the client using a notification. This model has the advantage that for workspace wide diagnostics the server has the freedom to compute them at a server preferred point in time. On the other hand the approach has the disadvantage that the server can’t prioritize the computation for the file in which the user types or which are visible in the editor. Inferring the client’s UI state from the [textDocument/didOpen](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_didOpen) and [textDocument/didChange](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_didChange) notifications might lead to false positives since these notifications are ownership transfer notifications.
> The specification therefore introduces the concept of diagnostic pull requests to give a client more control over the documents for which diagnostics should be computed and at which point in time.
https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_pullDiagnostics
For our server, we need one more feature.
> The [workspace/diagnostic/refresh](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#diagnostic_refresh) request is sent from the server to the client. Servers can use it to ask clients to refresh all needed document and workspace diagnostics. This is useful if a server detects a project wide configuration change which requires a re-calculation of all diagnostics.
This is needed because in the current implementation we re-lint the opened files when some `.oxlintrc.json` configuration is changed or `fix_kind` server configuration. Instead of re-linting, the server will send this request to the client.
----
This will be a breaking change for other clients which are sending the `run = onType | onSave` configuration, but are supporting all needed specs for the pull diagnostics mode. The client should instead implement their own configuration and sending the `textDocument/diagnostics` to the server when needed.
Moved the option inside `flags` to the "root" config, you IDE's can implement a simpler UI.
The old `flags` are still supported and gets remapped to the new config.
> This PR adds support for the `fmt.configPath` configuration to the language server, allowing users to specify a custom path to the oxfmt configuration file instead of using the default `.oxfmtrc.json` in the workspace root.
First try on formatter integration.
The server will only tell the client, that is supports `formatting` when `fmt.experimental` is `true`.
It will respect the flag in `initialize`, `did_change_configuration` (changing configuration), or `did_change_workspace_folders`.
It will not tell the client, it does not support formatting when the configuration is changed to `false`.
This can be optimized but has no high priority, because the client needs to send the request and the `ServerFormatter` needs to be set. The last requirement is then false.
Make `WorkspaceWorker.option` optional, so we the servers knows when the configuration in `initialize` or `initialized` (with `request_workspace_configuration`). Before the server knew it, by looking at the `WorkspaceWorker.server_linter` instance.
closes#11618
VSCode users are now able to set the severity of unused disabled directives via `oxc.unusedDisableDirectives`.
Other Clients can use this options too, by passing `unusedDisableDirectives` as a new config key.
This PR introduces a new Options structure, which will be used for `initialize` and `workspace/didChangeConfiguration`.
This is needed for multi workspace support, or else we will do the less performance-way with sending a server-request to the client.
Updated the docs to reflect how to use the new configuration structure
Still used the old structure as a fallback, because the IntelliJ plugin ❤️
This pull request focuses on optimizing the implementation of the
`oxlint.applyAllFixesFile` vscode command by adding the command
interface to the LSP instead of requesting all code actions and
executing the preferred ones. This PR contains an abstraction above the
LSP workspace commands, the `oxc.fixAll` command itself and minor
changes to the vscode extension.
Since the `workspace/executeCommand` handler is new, I've created an
abstraction to register the commands and parse their arguments. While it
isn't necessary, I feel like it makes future additions to the LS easier.
I tested the command in both vscode and neovim, doubt it will be hard to
use this in the zed / intellij projects.
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Ref #7456
- Creates a custom action in the language server that applies all
auto-fixes for a given file.
- Updates VS Code to use the custom action with a command to apply fixes
for the currently active text editor.
leaysgur