refactor(linter): move around some config store logic

[camc314]

this PR moves all of the config resolution for a single file into the ConfigStore structure, rather than half existing in oxc_linter and half in oxlint crates

[camc314]

• fix(linter): delay merging of oxlintrc configs #10835
• refactor(linter): move around some config store logic #10861 👈 (View in Graphite)
• refactor(linter): extract nested config searching to a fn #10860
• main

---

How to use the Graphite Merge Queue

Add either label to this PR to merge it via the merge queue:

• 0-merge - adds this PR to the back of the merge queue
• hotfix - for urgent hot fixes, skip the queue and merge this PR next

You must have a Graphite account in order to use the merge queue. Sign up using this link.

An organization admin has enabled the Graphite Merge Queue in this repository.

Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue.

This stack of pull requests is managed by Graphite. Learn more about stacking.

[codspeed-hq]

CodSpeed Instrumentation Performance Report

Merging #10861 will not alter performance

_{Comparing c/05-07-refactor_linter_move_around_some_config_store_logic (79819cc) with main (ccda8f0)}

Summary

✅ 36 untouched benchmarks

[camc314]

@Sysix does this approach make sense to you and do you see any concerns around it regarding the language server?

The main point here, is there'x 1x ConfigStore now, and it stores all nested configs, including resolution of getting those configs (applying overrides ect).

Eventually, this will be built via ConfigStoreBuilder - we could return a list of files to tell the language server to watch for changes (thinking config extends ...), at which point, we can just re-build the config store to get the updated configuration

[Sysix]

@camc314 after #10775 only the ServerLinter is responsible for nested configs.
The changes look good for me.

Optimizing the logic for the language server is preferred, but I choose against it for the moment.
The Language Server is working now like this:
Client Request → Language Backend
Language Backend → Searching for the right Worker
Workspace Worker → Requesting / Recreating the Server linter
Server linter → Building nested configs on (re)creation

we could return a list of files to tell the language server to watch for changes (thinking config extends ...), at which point, we can just re-build the config store to get the updated configuration

This is a bigger problem. Because the watchers are currently on the client side. The client should not know the architecture of the linter

[camc314]

@camc314 after #10775 only the ServerLinter is responsible for nested configs. The changes look good for me.

Optimizing the logic for the language server is preferred, but I choose against it for the moment. The Language Server is working now like this: Client Request → Language Backend Language Backend → Searching for the right Worker Workspace Worker → Requesting / Recreating the Server linter Server linter → Building nested configs on (re)creation

this sounds expensive to me, but I don't fully understand how the language server works.

we could return a list of files to tell the language server to watch for changes (thinking config extends ...), at which point, we can just re-build the config store to get the updated configuration

This is a bigger problem. Because the watchers are currently on the client side. The client should not know the architecture of the linter

Got it. Do you know how other lsps implement this?

[Sysix]

this sounds expensive to me, but I don't fully understand how the language server works.

It is, but this should only be noticeable when changing configuration / oxlintrc.json.
We can improve it in the future :)

Do you know how other lsps implement this?

I know the most LSP will create Server File Watchers. Maybe some can tell the client to watch for files with registerCapabability?.
Creating File Watchers on the server side is not recommended:

Servers are allowed to run their own file system watching mechanism and not rely on clients to provide file system events. However this is not recommended due to the following reasons:

• to our experience getting file system watching on disk right is challenging, especially if it needs to be supported across multiple OSes.
• file system watching is not for free especially if the implementation uses some sort of polling and keeps a file system tree in memory to compare time stamps (as for example some node modules do)
• a client usually starts more than one server. If every server runs its own file system watching it can become a CPU or memory problem.
• in general there are more server than client implementations. So this problem is better solved on the client side.

https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workspace_didChangeWatchedFiles

[camc314]

Merge activity

• May 8, 7:20 AM EDT: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• May 8, 7:20 AM EDT: camc314 added this pull request to the Graphite merge queue.
• May 8, 7:27 AM EDT: Merged by the Graphite merge queue.