Repository navigation
Deprecate the "dart.onlyAnalyzeProjectsWithOpenFiles" LSP setting #61742
Description
The LSP server currently supports a config setting onlyAnalyzeProjectsWithOpenFiles which causes it to ignore the workspace folders provided by the client and instead infer the analysis roots from the open files. The original motivation for this was that some terminal editors would set the workspace root as the current working directory (or users home directory) when opening a single file, which would trigger analysis for a lot more than the current file. In the case where you're using a terminal editor to edit a single file, this worked reasonably well.
However, in editors like VS Code this setting can have a significant negative impact on general performance. Every time a new file is opened or closed it has the potential to change the analysis roots, which is a fairly expensive operation and blocks all other requests for the duration. This means if you open a file in a new project (for example by Ctrl+Clicking to navigate) you might see a long delay before things like semantic tokens are available. To compound this, when pressing Ctrl while hovering over a symbol, VS Code sends requests to open and then immediately close the file. If you Ctrl+Click this might result in three requests for open+close+open.
There have also been changes to the server since this setting was added that make the trade-off of using this setting worse (like Pub Workspaces and other general improvements to performance), and some of the editors I've checked where this may have been useful (such as Neovim) now seem to have support for correctly setting reasonable roots when opening files.
As such, I believe we should drop support for this setting. I think it will overall make the server more responsive while working. I'm opening this issue as somewhere to collect feedback from those that are using it.
If you are using it and think removing it will make things worse, please comment below with:
- Your editor and LSP Client (if not built-in)
- Some information about the size/structure of your project
- Whether you are using Pub Workspaces or not
- Your OS (if Windows, whether you have Windows Defender exclusions for the analyzer cache folder)
- The version of the SDK you're using
- Some examples of differences in timings you see with/without this setting enabled
Activity
Show a one-off warning about onlyAnalyzeProjectsWithOpenFiles
Show a one-off warning about onlyAnalyzeProjectsWithOpenFiles
Show a one-off warning about onlyAnalyzeProjectsWithOpenFiles
Show a one-off warning about onlyAnalyzeProjectsWithOpenFiles
Levi-Lesches commentedon Dec 26, 2025
Hi! I'm using this setting. First of all just wanted to shout out https://xkcd.com/1172
My setup is that I use one VS Workspace for all of my projects, and just add the directories to the sidebar. This includes projects in not just Dart, but also some folders with several Dart projects inside (like
work,personal. etc). This makes it very handy to jump between projects without ever needing to open the Windows Explorer, and on any given week I'm usually working on the same 1 or 2 projects.With this setting disabled, the plugin wastes time trying to analyze all of my other projects, and if I've recently run
flutter cleanon one, I get thousands of errors for a project I'm not even working on. I do use Pub Workspaces though, and would still appreciate any workspaces that contain a file I'm viewing to be analyzed. I'm not so concerned about the latency when switching between projects, since I almost always have at least 1 or 2 tabs open for the project I'm working on (ie, I don't close all, I just open new tabs as necessary and close outdated ones).Info:
flutter cleana bunch). Setting the extension to automatically rundart pub getwhen needed would fix that issue, but wouldn't prevent all the other non-pub issues from polluting my viewDanTup commentedon Jan 26, 2026
@Levi-Lesches thank you for the details!
I can see how this setting would be useful for how you're working, but I worry about trying to support this setup generally. That it hides errors for projects you're not in is a side-effect of what we're doing and wasn't the goal. The purpose of this setting was purely about the performance of analyzing a larger workspace rather than to affect the functionality.
While it helps for analysis specifically, there are many assumptions in the Dart-Code extension that the folders you have open are ones that you care about. This means that while the "other projects" are hidden from analysis, they won't be hidden from other functionality, such as the Test Explorer, "Go to Symbol in Workspace", "Find in Files" and prompts for where to run commands that require a project root.
It's possible that you'd have a more consistent experience using Workspaces (VS Code workspaces, not Pub workspaces). With these you can create workspaces of just specific folders (which don't have to necessarily be grouped together on the file system) and then all of the features across VS Code would use those. You can even set workspace-specific config if you want slightly different settings in each (including themes, if you want them to be easily distinguishable).
I keep a folder of my workspaces pinned to the explorer sidebar, so switching project is just File -> Open Workspace, and then select one of these:
It is extra clicks when you do switch between projects, but since you said you tend to work on the same 1-2 projects each week, perhaps the benefits will outweigh that. I would be interested to know how you think that compares to your current use of this setting overall.
Levi-Lesches commentedon Feb 16, 2026
Hm, I don't think I'm ready to fully switch to VS Code Workspaces. I get the idea, but I use the sidebar as a list of projects I could jump into. When I have free time to take on a new task, I look to the sidebar and pick something that I think could use some work. At the very minimum, even if I used smaller workspaces, I'd still have more than one Dart project in it, at least to pull code from one as a reference for the other.
I took another look at your top comment and realized that while my code was in a Dev Drive, the analysis server itself wasn't being excluded by Windows Defender 🤦. Pretty significant performance boost based on
VS Code > Reload Window, so thanks! Based on this, I'm (subjectively) not seeing a significant performance penalty on my machine with the setting off. With all my many projects open and the setting turned off, it only took a handful of seconds for symbols to start having hover hints and such ready. Only a little longer than the same as with the setting on (by my rough count, 5 seconds vs 8).So maybe the real focus for me is the visibility of the analysis problems. I don't mind if the other projects are analyzed, or appear in the testing tab or debug tab. I actually appreciate being able to quickly launch any project. Even though I only focus on 1-2 projects in a week, I often find myself jumping in to fix a quick typo or bug in an unrelated project between breaks.
But I would appreciate it if the Problems tab only showed lints/warnings/errors for projects that I am actively viewing. I know there is a built-in setting to filter to your active file, but it's common enough to make a change in one file and break a different file in the same project. But I definitely don't want to see that a feature I half-implemented two weeks ago has 300 errors.
In short, if the setting changed from "only analyze open projects" to "only show analysis for open projects", I'd be happy. Hopefully that should make the changes on your side simpler too since the complexity of the setting is limited to just one UI option.
keertip commentedon Sep 10, 2026
@DanTup , has there been any movement on getting the problems view to display the info @Levi-Lesches is looking for? Do we know if there are other users of the "dart.onlyAnalyzeProjectsWithOpenFiles" setting. Have you any stats on that?
DanTup commentedon Sep 10, 2026
Of those opted-in to stats, 0.1% of Dart-Code users have this setting enabled in the last month. All of them would've ben shown a prompt stating that this setting is not recommend and may be removed (with a link to this issue). We only show the message once (to avoid being annoying) though, so it's hard to draw conclusions about how many users would miss this feature (and ofc we don't know what portion of them are actually opening workspaces with > 1 project, or if they still have it enabled just because we only prompted them once and there was no benefit to going into settings to unset it).
I don't think there's really a different way to provide what's described above - the request is for exactly what this setting does - allow you to open many projects, but have the analysis server behave as if you'd only opened the projects that contain the files you have open.
But to me, the current behaviour does not do this well for a few reasons:
My personal feeling is that this probably isn't a feature worth supporting and it's better to open only the project(s) being working on. If you want to jump into another project for a short period, VS Code is pretty light and you can open another window for that project (I very frequently have 3-4 VS Code windows open with different projects). Of course, I haven't been using this setting and have had to try and determine whether it's a factor when debugging performance issues, so my opinion is skewed and perhaps shouldn't be a deciding one 🙂
(cc @bwilkerson for his thoughts)
bwilkerson commentedon Sep 10, 2026
tl;dr I think we should probably get rid of this setting. I don't think it does what users want.
It sounds like there are at least two use cases here.
IIRC, the original reason for the setting was to improve performance. While the setting does that, it comes at a cost and I think there are better ways to address the performance issues. Some of the performance problems have been addressed already, and we will continue to work on improving performance.
The more recent ask is for a way to express a working set. (Where some portions of the UI, such as the Problems view, work differently based on whether a folder is in the working set.) This flag doesn't do that (unless the working set would always be a single package, but that's too limiting).
I'm not entirely certain that supporting a working set model is something we can do, or at least can do well. This is really something that needs to be built in to the IDE. I've seen various attempts over the years. Eclipse has Mylyn, which is a task-oriented model of this. That is, each task has its own working set and you can switch between tasks. IntelliJ has support for multiple workspaces and even the ability to enable or disable various folders within each workspace (though I think you have to do it manually). VS Code appears to use a workspace model as well, with the ability to have each workspace in a separate window. Both models have advantages and disadvantages, and it isn't clear whether any of them are perfect.
But I do think that it would be hard, if not impossible, for a plugin to implement this kind of feature without IDE support.
Levi-Lesches commentedon Sep 10, 2026
@DanTup I appreciate your commitment to collecting user feedback and generally how you value the user experience in all these issues I read. I completely understand my situation of jumping between 5 random, unrelated projects that I mostly complete and then kind of abandon isn't exactly the intended use of this plugin (but like, we all do that, right? 😅)
If it makes the plugin easier to maintain, I agree with removing it. Your suggestion of opening multiple windows is reasonable, and I can put those windows in separate Windows Desktops so they don't get in the way. It'll be a shift in my flow, but I've recently lost most of my free time anyway, so maybe it's good timing.