Add a way to extract custom tabs out of flutter/devtools and into a separate repository

[rrousselGit]

Hello!

Problem

With the way tabs are currently setup, the provider tab (and the PR for the riverpod tab) inject custom code directly within this repository. Same goes for the issues related to these tabs.

That works for now, but it's a bit difficult to maintain. I think ideally, the source code should live in a separate repository. For example, I think it'd be preferable if the source code for the Riverpod PR #4210 was instead located in Riverpod's repository.

Proposal

Would it be reasonable to extract the source for those tabs into a separate package, published on pub? The flutter/devtool repository would then depend on those packages and inject their tab in the app.
Issues would then be redirected to the correct repository. Meaning that issues with the provider tab would be hosted in the provider repository, not here.

Due to how those tabs are intertwined with various classes from the devtool, this likely would require a bit of refactoring for this to work. More particularly, it probably would involve the creation of a devtool_core package, exposing things like Screen and EvalOnDartLibrary

Also, for security concerns, I could understand the desire to make the version of that package fixed. As in doing:

name: devtool_app

dependencies:
  # using tight constraints to avoid injecting code
  riverpod_devtool: 1.0.0

So when new versions of the tab are published, a PR would be made to flutter/devtool to bump that version number. The new version could then be reviewed to make sure everything is alright

Would that be reasonable?

[rrousselGit]

Of course, in the ideal world, this wouldn't be needed.

I think the ideal solution would be something like build_runner, which has a plugin mechanism. This probably would involve a lot of work though.
Consider this issue kind of as an MVP to a plugin mechanism.

[adsonpleal]

@rrousselGit I think this issue is related #1632

[rrousselGit]

It's related yes. This proposal is more like a baby step toward #1632.

This wouldn't require the creation of a custom build mechanism. It's only moving some of the source code. So the scope of the work needed is a lot smaller

[kenzieschmoll]

Thanks for filing the issue, Remi. In general, I agree with you that this is a problem and it is certainly one we are thinking about (especially with the new Riverpod tab coming through the pipeline). A few thoughts:

The flutter/devtools repository would then depend on those packages and inject their tab in the app.

The only problem with this is that we have restrictions on what libraries we can depend on due to the fact that our code base is rolled into the internal google codebase. So every dep we take in devtools will have to be imported to the internal google code, which has caused issues in the past and would limits what package authors can depend on from their custom tooling.

Because of this, I think we will still need to push for a full plugin mechanism - something that allows custom tooling code to live in a package's repo, and allows DevTools to load it in an iFrame.

creation of a devtool_core package, exposing things like Screen and EvalOnDartLibrary

Creating a core library will likely be part of the implementation for #1632 as well.

[kenzieschmoll]

Fixed by #1632