Provide an API to create extensions for the devtools

[simc]

It would be very helpful if there was a way to create custom extensions for the devtool. For example, I'd like to write an extension to inspect the contents of the Hive DB. But I think there are many interesting extensions, the community could create.

The Stetho tool from Facebook allows something similar for the Chrome DevTools.

And the flipper tool also has a very powerful way to create extensions. It even allows creating custom UI.

[britannio]

Few use cases

• Monitoring network activity for a network package e.g. dio or graphql
• Tracking state changes in Redux
• Creating custom dashboards with key metrics for your app
• Inspecting databases as @leisim suggested
• ...

[cedvdb]

The use cases are legion tbh, any kind of inspection of state is useful there. whatever state.

I would also like the possibility to have extension, but if that's not planned if there was a message bus mechanism where one could start another app that connects to that bus and display the required information with a desktop app it would be nice.

Let me rephrase this, if extensions is not planned, it would be nice to have the ability to:

• start a flutter app that emits messages.
• start another app that displays those messages.

Certainly this is doable today but my guess is that the process will be too involved (development wise) to not be solving 2 problems (making the extension + make a communication mechanism).

[simc]

It would even be helpful to allow third parties to access an active debugging session without requiring the user to find the websocket link in the logs.

My use cases:

• Isar Inspector
• Custom integration test VSCode extension

[simc]

@kenzieschmoll Is there something we could help with to make this happen? Or are there alternatives? Riverpod and Provider are integrated into devtools. Can anyone submit an extension?

[jacob314]

Here's a link to our in progress design on supporting Flutter DevTools Plugins. Comments appreciated! https://docs.google.com/document/d/1BWX8YQ962Vsx-EUDuDHRG7RX94fJlZSDRu299YRwasE/edit

[simc]

@jacob314 Wow that is incredible 😍 can't wait to build some plugins

[rrousselGit]

👋
Out of curiosity, when could this be made available and is there anything we can do to help? 🙏

I'm asking because I'm honestly considering making my own plugin mechanism through a custom VScode extension which would allow folks to contribute tabs.
I was considering a VScode extension because it enables the plugin mechanism to access the full VScode API.
So plugins could provide custom commands or implement their own "open a file at a given offset".

But if we're going to have plugins in a reasonable timeframe, this project may not be worth it anymore (since an official solution would have a bigger reach)

[jacob314]

@kenzieschmoll is in the process of kicking this effort back off. VSCode API integration is interesting and we have use cases like editing Flutter widget properties where that would be helpful as well. It would be great to have you collaborate on the implementation of the official solution for this.

[rrousselGit]

It's a bit unclear to me on what I could do to help. Do you have anything more specific?

Honestly, I wouldn't mind contributing to various aspects of the plugin mechanism. VScode API or not.

[kenzieschmoll]

Hi @rrousselGit. I'm going to prioritize working on this design. I will keep you posted when I have some more specific details to share. Thanks!

[kenzieschmoll]

The design for this feature is out for review:

1. Flutter Developer Tooling Plugins. This doc aims to design a solution for DevTools and IDE plugins

Related:

1. Dash Tooling Plugin Strategy. This doc aims to drive alignment on the "big hooks" for plugins across the broader flutter ecosystem. There is some overlap with the first doc, but this doc also involves some elements to drive consistency across analyzer and flutter tools plugins.

[kenzieschmoll]

I've been working on a prototype to provide a proof of concept for the above designs.

Screencast link: https://screencast.googleplex.com/cast/NTk2MzgyOTQ4MjYxODg4MHxiODFhYjFiOC0yNA
Or watch video: DevTools Plugins Prototype.webm

This work is subject to change and needs a lot of cleanup, but early & rough prototype available with the combination of the following changes:

• DevTools: https://github.com/kenzieschmoll/devtools/tree/tooling-extensions
• DevTools Server (package:dds in the dart SDK): https://dart-review.googlesource.com/c/sdk/+/305043.

For testing, I am running app_that_uses_foo from here, which imports the foo_package from the same repo: https://github.com/kenzieschmoll/test_apps/tree/main/tooling_plugins, and I am connecting that app to devtools, built and served with dart devtools/tool/build_e2e.dart.

Note: for this to work properly, the app_that_uses_foo/.dart_tool/package_config.json entry for "foo_package" needs to use an absolute path, not a relative one:

    {
      "name": "foo_package",
      "rootUri": "../../foo_package", // Change to an absolute path
      "packageUri": "lib/",
      "languageVersion": "3.1"
    },

[kenzieschmoll]

Implementation Tracker

DevTools app [COMPLETE]

Task list

• Conditionally show screens when extensions are available
  • Add logic to conditionally show available extensions #6048
• Implement extension screen framework in DevTools with embedded iFrame
  • Add skeleton for extension screen views and controllers #6054
  • Add embedded iFrame logic for DevTools extensions #6060
  • Load extensions from DevTools server instead of using stubs. #6097
  • [more to come]
• Implement extension detection through DevTools server
  • Add a server endpoint for serving devtools extensions #6094
• Implement extension activation through DevTools server
  • Add extensionActivationState endpoint to the devtools server #6111
  • Add the extension settings dialog #6138
  • Add ability to enable and disable an extension from the extension screen #6140
• Add an end to end integration test that loads an extension from a test app, activates / deactivates, and messages back and forth - Add end to end integration test for DevTools extensions #6373
• Polish experience Polish DevTools Extensions before releasing #6272
• Enable experiment flag
  • Enable DevTools Extension support by default. #6384
• Add an opt-in setting for default tab visibility behavior: Add a setting for making tab visibility opt in for DevTools extensions #6376
  • Add extension setting to show only enabled extension screens #6383

package:devtools_extensions [COMPLETE]

Task list

• create package
  • Initial commit for package:devtools_extensions #6055
• create the shared api that both DevTools and DevTools extensions will use
  • ping / pong (these should only be used by DevTools and the DevTools extension template)
  • vmServiceConnection: request the connect vm service uri from DevTools
  • showNotification: the extension requests that DevTools show a toast notification Add showNotification and showBannerMessage to extension API #6276
  • showWarning / showError: the extension requests that DevTools shows a banner message Add showNotification and showBannerMessage to extension API #6276
• create a template that extension authors will use to create devtools extensions
  • Add DevToolsExtension template to devtools_extension package #6066
• establish vm service connection in DevToolsExtension wrapper
  • Support vm service connection for DevTools extensions #6175
• add example to package_devtools_extensions
  • Add example to devtools_extensions package #6069
• add an end to end example starting from package:foo instead of only showing an example of using package:devtools_extensions
  • Add an end to end example of for building a DevTools extension #6299
• ship a command that users can run to build their extension and copy to the parent package directory. This command should accept parameters for the extension app location and the parent package location
  • Ship a build_and_copy command with the devtools_extensions package #6259
  • Add exception handling to build_and_copy command #6298
• create a simulated devtools environment that extensions can run in for easy extension development:
  • Add DevToolsExtensionHostInterface and clean up some service management for extensions #6250
  • Add a simulated DevTools environment for developing extensions #6251

package:devtools_app_shared [COMPLETE]

Task list

• create a new package to hold shared ui and service management components that extensions can use: Create and publish package:devtools_app_shared #6208

package:extension_discovery [COMPLETE]

Task list

• develop a package to detect available extensions based on the .dart_tool/package_config.json file for an app @jonasfj
  • Initial version of package:extension_discovery dart-lang/tools#129
• add package:extension_discovery as a DEP in the Dart SDK (https://github.com/dart-lang/sdk/wiki/Adding-and-Updating-Dependencies)
  • https://dart-review.googlesource.com/c/sdk/+/317804
• roll package:extension_discovery into g3.

package:devtools_server [COMPLETE]

Task list

• use the extension detection package in devtools_server to find available extensions
  • Use package:extension_discovery to detect DevTools extensions #6139
• add logic to read / write extension activation states from a devtools_options.yaml file
  • Add extensionActivationState endpoint to the devtools server #6111
• serve extension assets from the DevTools server
  • https://dart-review.googlesource.com/c/sdk/+/305043

Extensions land well

Task list

• Write the first DevTools extension and publish (package:provider?)
  • Tracked at Create a DevTools extension for package:provider rrousselGit/provider#833
  • PR: Create DevTools extension for package:provider rrousselGit/provider#832
• Write documentation for extension authors - Add initial README.md for package:devtools_extensions #6255
• Create a Discord channel for DevTools extension authors (tracked at Create a devtools-extension-authors Discord channel  #6480)
  • #devtools-extension-authors
• Announce to the #package-authors Discord channel
• Announce to the Dash ecosystem summit attendees
• Write a medium article (tracked at Write a medium article for DevTools Extensions #6479)
• Create a Flutter social request to publicize extensions (tracked at Create a Flutter social request to publicize DevTools extensions #6481)
• Gather early adopters to write extensions and provide feedback

open questions / edge cases to consider

1. What if a user manually edits the devtools_options.yaml file? Maybe we should ask the analysis server to watch this file and notify DevTools on changes (by proxy of the Dart tooling daemon eventually).
2. Should we watch the package_config.json file? Should the watch logic exist somewhere in package:extension_discovery? @jonasfj

[jonasfj]

Initial draft for a package:extension_discovery in dart-lang/tools#129

[rrousselGit]

Cool! Tell me whenever there's something I can play with :)

[kenzieschmoll]

This work has landed! Anyone wanting to write a DevTools extension should follow the instructions at https://pub.dev/packages/devtools_extensions. Extension support in DevTools just landed in the Dart SDK and should be available on Flutter master by the end of the week. This will be included in the next Flutter beta and stable releases. In the meantime, you can still develop your extension using the simulated DevTools environment described in the instructions.

package:provider has already published a DevTools extension for version 6.1.0-dev.1.

We are working on setting up a Discord channel specific to DevTools extension authors, but in the meantime you can reach out on Github or on the #hackers-devtools channel on the Flutter discord.

We are eager to hear early feedback on this feature and your input on how we can improve it!