Add a badge to pub.dev for DevTools extensions

[kenzieschmoll]

Can we add a badge when a package contains a devtools extension?

This would be great for discoverability from end users, but also great for us to be able to monitor the number of packages in the ecosystem that are providing devtools extensions.

@jonasfj

Longer term, we may want to look into including DevTools extension support as part of the package pub score as well, but that will take more thought / design.

[parlough]

In the meantime, you can suggest a standard pub topic such as devtools-extension or even just devtools that those packages should specify, then link to that topic.

As for monitoring the number of packages providing one, would viewing the list of packages that depend on devtools_extensions suffice? https://pub.dev/packages?q=dependency%3Adevtools_extensions

[kenzieschmoll]

Suggesting a pub topic could work in the interim. It would be nice to have this automatically detected though in case an extension author forgets to add a topic

As for monitoring the number of packages providing one, would viewing the list of packages that depend on devtools_extensions suffice? https://pub.dev/packages?q=dependency%3Adevtools_extensions

Unfortunately no, because the package that provides a Devtools extension will not actually depend on devtools_extensions. The DevTools extension, a flutter web app, will depend on devtools_extensions, but only the pre-built web assets will be included in the parent package under extension/devtools/build

[parlough]

Suggesting a pub topic could work in the interim. It would be nice to have this automatically detected though in case an extension author forgets to add a topic.

That makes sense and I think a badge would be super cool too! I'd definitely look for it when considering new packages :)

Unfortunately no, because....

Ah, I didn't realize that. Then a special badge makes even more sense.

---

As a side note, depending on the way the program continues, it might be interesting if having a DevTools extension (when possible) is a plus for consideration as a Flutter Favorite.

[jonasfj]

Suggesting a pub topic could work in the interim. It would be nice to have this automatically detected though in case an extension author forgets to add a topic

Low tech solution: We make a script that downloads the latest version of each package on pub.dev, and checks if they contain an extension/devtools/config.yaml.

---

I do wonder if we want to codify the extension/<package>/config.yaml concept to such an extend that we create a search query expression on the form:

• extends:<package>, which will match any package containing extension/<package>/config.yaml.

That way, you'd be able to create a link to search results for all packages contain a devtools extension.

Or maybe we could even do: file:<path> and have it match any package that contains a file or folder at <path>.

So one could search for file:extension/devtools/config.yaml :rofl:

@isoos thoughts on this?

---

As a side note, depending on the way the program continues, it might be interesting if having a DevTools extension (when possible) is a plus for consideration as a Flutter Favorite.

I think we should be careful with this sort of thing. It's a plus if it's useful to have and the extension is useful and works well (and there are tutorials / documentation for how to use it).

But I'm pretty sure that most packages should never need devtools extensions. Like my retry package probably doesn't need it :rofl:

[isoos]

Or maybe we could even do: file: and have it match any package that contains a file or folder at .

I think this is a good reason to introduce new kind of indexes applied to search, and an extensible model for pana to output them. I'm already thinking on how we can evolve the current pub-data.json approach, such use cases would be useful to plan for it.

[kenzieschmoll]

I do wonder if we want to codify the extension//config.yaml concept to such an extend that we create a search query expression on the form: extends:<package>, which will match any package containing extension/<package>/config.yaml.

So for the devtools case this would be the query "extends:devtools"? That sounds reasonable (although maybe not the most discoverable for users). But as long as this is documented along with all the other pub search queries, this sgtm. I wouldn't expect users to be querying for this often (but who knows, maybe they would like to).

What type of UI element can we add to pub.dev? A couple thoughts I had were:

1. Adding a chip "DevTools extension"
2. Adding a banner similar to flutter favorites

What I like about the chip is that we could show this in the search results (like the dart 3 and flutter favorite chips here)

[parlough]

My concern with a chip or badge like that, is what if other packages want to provide an extension mechanism? Or (in the future 🤞) packages that provide an analysis server plugin/extension? A package could end up providing a bunch of extensions, so it seems any solution should prepare for that possibility.

[jonasfj]

So for the devtools case this would be the query "extends:devtools"? That sounds reasonable (although maybe not the most discoverable for users).

The point would be that devtools documentation can include a link to the search. Or we can make a dart.dev/go/devtools-extensions link that redirects to the search.

People won't easily find such complicated search queries, but we can link to them.

---

We could add a chip thing. But if we make the chip look too good, people will add devtools extensions to packages that don't need one 🙈🤣

Honestly, the thing with badges and chips is that eventually there will be too many of them. Then we risk having a tacky 90ties style gif website, hehehe, 😅

Of course, we could also just add some badges and put a date in the calendar for 2 years out to evaluate if the badge is still relevant.

---

I do think that we should consider solving this the low tech way.

You could imagine that something like: dart run devtools_extensions build_and_copy could run some validations. Basically, it could do some checks to see if you're following best practices. For example, it could check:

• extensions/devtools/config.yaml is sane.
• pubspec.yaml has a topics section, and the topic devtools-extension is added.
• The README.md contains a line on the form: [[!devtools extension](https://dart.dev/static/devtools-ext-badge.png)](https://dart.dev/go/devtools-extensions).
• Probably other things you can check too...

You could also make a package:devtools_extension/test.dart library which makes it easy to run these validations. And then encourage devtools extension authors to make a test like:

// test/devtools_extension_test.dart

import 'package:devtools_extensions/test.dart';

void main() => testDevtoolsExtension();

(You might need to out it in a package:devtools_extension_test_util package to avoid indirect runtime dependency on package:test.

My point was: a low tech solution would be to make a badge image and encourage people to include it in their README, if they have a devtools extension. It's simple, low tech and works on GitHub too!

Similarly, we could just encourage extension authors to add a topic indicating they have a devtools extension. Then searching for that topic makes it easy to discover packages with devtools extensions, and you can link to such a search from devtools and devtools documentation.

Most package authors won't write devtools extensions, so there is an argument for crude and low tech solutions :)

[polina-c]

One more badge for packages, that may become needed this year, is 'Leak Free'. The badge 'Leak Free' is dependency-sensitive like 'Null Safe': if your dependency has memory leaks, you may have leaks too.

See leak_tracker

[bkonyi]

The point would be that devtools documentation can include a link to the search. Or we can make a dart.dev/go/devtools-extensions link that redirects to the search.

People won't easily find such complicated search queries, but we can link to them.

Would we be willing to add a section on the pub.dev homepage to showcase packages / DevTools extensions that would also link to this query, similar to what we do for "Top {SDK} packages"?

WRT to badges, would it make sense to instead list DevTools as a platform rather than creating a separate badge? This would allow for packages that ship with DevTools extensions and (future) standalone static DevTools extensions to be grouped together for easy discovery.