**BREAKING CHANGE**: VSCode-Client does not watch for `eslint`
configuration files. Default value for `oxc.configPath` is now
`.oxlintrc.json` instead of `.eslintrc`
after changing `settings.json`, the changes whould not to updated
internally.
With this PR the updated values get passed to the language-server. 🥳
probably closes https://github.com/oxc-project/backlog/issues/132
because we also support the oxlint config
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
I don't think we need two separate channels for output. This replaces
the 2 existing channels with a single channel that allows configuring
the log level.
Ref #7136
Currently `oxc-vscode.trace.server` needs to be used to enable trace
logging for the language server. This fixes it so that
`oxc.trace.server` can be used. I can't find any guidance on what should
be used for the language client id. The VS Code ESLint plugin uses
"ESLint", so I think this change should be fine.
Ref https://github.com/oxc-project/oxc/issues/7136.
Whenever the language server sends a `window/showMessage` event, VS Code
will listen and display a notification or log a message based on the
severity level of the message.
The language server doesn't currently send this event. I'm going to
follow up with a separate PR for that.
Ref https://github.com/oxc-project/oxc/issues/6988
Watch eslint and oxlint config files for changes. When these files
change, a `didChangeConfiguration` event will be sent to the language
server.
Ref https://github.com/oxc-project/backlog/issues/132.
This currently fails because it sends over data that the language server
isn't prepared to deserialize. This updates to send over the correct
`LanguageServerConfig` type.
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Syncs up the options from the language server `Options` struct with the
values that the extension supplies.
I tend to avoid `toJSON` because it will be used by `JSON.stringify`
when called and it's not well known.
There's no reason that `LanguageServerConfig` and `Config` have to both
exist, but I think two types is easier to understand.
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
> Closes https://github.com/oxc-project/backlog/issues/132
Unify configuration logic into `ConfigService`. This allows for type-checked
config settings. It also lets us make sure config values are synced with what
the user has set in their vscode settings.
This PR is a breaking change since it also unifies config key prefixes (`oxc`
and `oxc_language_server` -> `oxc` only)
closes#6382
It seems we cannot support `oxc_language_server` by directly reusing
code from `coc-oxc`, at least not on Windows, because it requires an
`.exe` executable.
I will take some time to study the implementation of `Biome` to enhance
our vscode plugin.
1. Use `log::info` to print some informantion which we would want to
display in release mode,
2. Add config to switch back `debug` log level in development mode.
1. Fallback logic about `document/didChangeConfiguration`
2. normalize vscode naming
3. change `configuration` section name from `oxc-client` to
`oxc_langauge_server`.
