You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Connect to the Dart Tooling Daemon from the Analysis Server #55629
An API will need to be established on the analysis server that will allow the IDEs to set the DTD URI on the analysis server. Once a DTD URI is received, the Analysis server will need to use package:dtd to connect the the Dart Tooling Daemon, and then register any methods or services that it will provide to other DTD clients.
Tracking issues for sending the DTD URI to the analysis server:
The work for this has been done for a while, but it's behind some flags that we should consider removing.
Dart-Code has a flag dart.previewDtdLspIntegration that must currently be set to true for it to tell the analysis server to connect to DTD
I suggest we remove this flag for the next Dart-Code release and instead gate it on Dart SDK >= 3.8.0-0, which means the current bleeding-edge builds will have this connected (no handlers will currently be registered, but it will give more coverage of the server with this connection active). @bwilkerson WDYT?
Dart-Code has another flag dart.experimentalDtdHandlers that tells the server to register DTD handlers marked as experimental
We should keep this flag as-is, but change the property editor handlers to be not marked as experimental once (removing the experimental/ prefix from their method names) when we think they are good to ship (or at least we don't anticipate any breaking changes).
Since this changes the method name, we will first need to update the property editor to support the new names (in addition), which is something @elliette prepared previously, but I suggested delaying until we're sure the API is good.
After that change has landed in the property editor, we can rename the methods (and once that's rolled into Flutter used by DevTools, the code for the experimental name could be removed).
I think we'll probably want to land flutter/devtools#8990 and then get a version of DevTools with that change into the Dart SDK before we land my CL to minimize disruption for anyone testing out the property editor.
Activity
kenzieschmoll commentedon Aug 16, 2024
@DanTup is actively working on this issue.
DanTup commentedon Mar 5, 2025
The work for this has been done for a while, but it's behind some flags that we should consider removing.
dart.previewDtdLspIntegrationthat must currently be set totruefor it to tell the analysis server to connect to DTDI suggest we remove this flag for the next Dart-Code release and instead gate it on Dart SDK >= 3.8.0-0, which means the current bleeding-edge builds will have this connected (no handlers will currently be registered, but it will give more coverage of the server with this connection active). @bwilkerson WDYT?
dart.experimentalDtdHandlersthat tells the server to register DTD handlers marked as experimentalWe should keep this flag as-is, but change the property editor handlers to be not marked as experimental once (removing the
experimental/prefix from their method names) when we think they are good to ship (or at least we don't anticipate any breaking changes).Since this changes the method name, we will first need to update the property editor to support the new names (in addition), which is something @elliette prepared previously, but I suggested delaying until we're sure the API is good.
After that change has landed in the property editor, we can rename the methods (and once that's rolled into Flutter used by DevTools, the code for the experimental name could be removed).
bwilkerson commentedon Mar 5, 2025
That all sounds reasonable to me.
elliette commentedon Mar 5, 2025
SGTM as well! Opened flutter/devtools#8990 to support the non-experimental APIs
Remove the LSP DTD preview flag and use >= Dart 3.8
DanTup commentedon Mar 6, 2025
I've done (1) in Dart-Code (Dart-Code/Dart-Code@c6093c7) and I've prepared a CL to make the LSP handlers non-experimental in this CL here:
https://dart-review.googlesource.com/c/sdk/+/414060
I think we'll probably want to land flutter/devtools#8990 and then get a version of DevTools with that change into the Dart SDK before we land my CL to minimize disruption for anyone testing out the property editor.
[analysis_server] Mark editableArguments / editArgument as not-experi…