Skip to content
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

feat(editor): Support nested configs #9743

Merged
merged 1 commit into from
Mar 18, 2025

Conversation

nrayburn-tech
Copy link
Collaborator

@nrayburn-tech nrayburn-tech commented Mar 13, 2025

Based off of #9739.

Copy link

graphite-app bot commented Mar 13, 2025

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.

@github-actions github-actions bot added A-linter Area - Linter A-editor Area - Editor and Language Server C-enhancement Category - New feature or request labels Mar 13, 2025
Copy link

codspeed-hq bot commented Mar 13, 2025

CodSpeed Performance Report

Merging #9743 will not alter performance

Comparing nrayburn-tech:vscode-nested-config-support (8052ca5) with main (e408db8)

Summary

✅ 33 untouched benchmarks

@nrayburn-tech nrayburn-tech force-pushed the vscode-nested-config-support branch from 71c297f to adf7cfe Compare March 13, 2025 09:44
@nrayburn-tech nrayburn-tech force-pushed the vscode-nested-config-support branch 3 times, most recently from b72d997 to 1d31d94 Compare March 13, 2025 22:46
@nrayburn-tech nrayburn-tech force-pushed the vscode-nested-config-support branch from 1d31d94 to b4a0ac7 Compare March 14, 2025 06:22
@nrayburn-tech
Copy link
Collaborator Author

Marking as draft until I can accommodate changes from #9760.

@nrayburn-tech nrayburn-tech marked this pull request as draft March 14, 2025 08:21
@nrayburn-tech nrayburn-tech force-pushed the vscode-nested-config-support branch from b4a0ac7 to 909284b Compare March 14, 2025 10:10
@nrayburn-tech nrayburn-tech marked this pull request as ready for review March 14, 2025 10:12
@Sysix
Copy link
Collaborator

Sysix commented Mar 16, 2025

I am sorry, I had not time this weekend to check if this works as expected :)
Will try to look into it the next days

@nrayburn-tech
Copy link
Collaborator Author

No rush. I was looking at implementing this for IntelliJ and it has me second guessing my approach.

Should the client be sending the initial configs that are found OR should the language server search the root_uri for this instead? I'm not sure how much filesystem access should be done from the language server, which is why I did it this way originally. Maybe it's a non-issue though.

Unverified

This commit is not signed, but one or more authors requires that any commit attributed to them is signed.
@nrayburn-tech nrayburn-tech force-pushed the vscode-nested-config-support branch from 909284b to 8052ca5 Compare March 17, 2025 22:42
Copy link
Collaborator

@Sysix Sysix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should the client be sending the initial configs that are found OR should the language server search the root_uri for this instead?

My first idea was to do all the work on the server side, but after reading about the LSP Specification:

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

Tested it today and it worked 🥳

@Sysix Sysix merged commit 0973356 into oxc-project:main Mar 18, 2025
28 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-editor Area - Editor and Language Server A-linter Area - Linter C-enhancement Category - New feature or request
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants