Add logic for VS code to promote other VS code extensions

[kenzieschmoll]

As part of the broader effort to support dart ecosystem extensions, we've designed a mechanism for a pub package to provide extension information as part of its package. For DevTools, this is the precompiled flutter web app that DevTools will embed. For VS Code extensions, the pub package can include a config.yaml file that tells the Dart-Code promotion which extension should be promoted:

my_package/
   lib/
      ...
   extension/
      vs_code/
          # contains meta data that VS code needs to point to another
          # extension on the VS code marketplace
         config.yaml

package:extension_discovery has logic to detect available extensions for a given .dart_tool/package_config.json file. Since this package is written in Dart, it cannot be used by the Dart-Code extension directly, so it will need to be called into from the Dart-Code extension by proxy of some other Dart service. Eventually, this would be a great fit for the Dart Tooling Daemon, but since this does not exist yet, we can use the DevTools server in the interim.

We can add an API to DevTools server that the Dart-Code extension can call, and the devtools_server will call findExtensions('vs_code', <path/to/package_config.json>) from package:extension_discovery on the Dart-Code extension's behalf.

Open Question
The element we still need to figure out is how to handle a monorepo workspace, where there are multiple package_config.json files available.

Related: Flutter DevTools Extensions

[DanTup]

@anderdobo @mosuem FYI - I wonder whether there's value in trying to use this for arb-editor (eg. have the Flutter/intl packages provide the recommendation)? It might need something extra (only show the recommendation if an arb file is opened?), but it might work out better than special handling for one extension?

[mosuem]

To recap an offline discussion: We will go with implementing the suggestion the extension itself for now, see #4719. We will possibly migrate to using this new feature. At the moment, the lack of a file filter ("only show the recommendation on opening .arb files") would result in too much noise for Flutter users.

[DanTup]

The element we still need to figure out is how to handle a monorepo workspace, where there are multiple package_config.json files available.

We could have the client just call a single API for each project it discovers in the workspace. A single API that takes a set of projects might be slightly more efficient, but I suspect internally it would just do the same anyway so it may be better to keep the API simple.

One slight tweak I'd make though (at least for the API called by the IDE) is to accept a package folder rather than the package_config.json directly. Dart-Code tries to avoid knowing about implementation details like .dart_tool/package_config.json (although it's unlikely to happen again, this file has moved in the past from .packages -> .dart_tool/package_config.json) so I'd prefer to keep that in the Dart world.

[DanTup]

I made a start on this at #4847 (and some SDK work in the DevTools server that needs tests before uploading).

@kenzieschmoll @anderdobo Jacob asked me today whether this includes transitive dependencies or only direct dependencies. It's using package:extension_discovery which I think reads the .dart_tool/package_config.json and might therefore include transitive dependencies -although I'm not sure whether that's the behaviour we want?

[kenzieschmoll]

Right now, package:extension_discovery includes transitive dependencies. @jonasfj if I remember correctly, there is not currently a way to distinguish between transitive and direct deps based on the package_config.json file, right?

If we did only want to include direct dependencies, I think this would be easy to do by modifying the extension_discovery package so that it has a parameter includeTransitiveDependencies, and when false, it could only return extensions whose parent package has an entry in the pubspec.yaml file at the project root that is passed in to the findExtensions method.

[DanTup]

@anderdobo @jacob314 are you happy with how this displays in my current PR?

In particular, we need to be sure the user is aware they are installing third-party code that is not owned/reviewed by the Flutter team.

@kenzieschmoll @jacob314

1. we discussed using a whitelist for initial testing of this. Do we have any extensions in mind, or should we land this with an empty whitelist?
2. did we conclude whether or not we're happy for this to look all (inc. transitive) dependencies, or do we need to update extension_discovery to handle only top-level dependencies (and if so, should it be only dependencies or also dev_dependencies?)

[kenzieschmoll]

1. we discussed using a whitelist for initial testing of this. Do we have any extensions in mind, or should we land this with an empty whitelist?

serverpod is a good first candidate. What do you need for the whitelist? just the package name? @vlidholt - can you confirm that serverpod is the correct serverpod package that you would like to promote your VS code extension from?

2. Did we conclude whether or not we're happy for this to look all (inc. transitive) dependencies, or do we need to update extension_discovery to handle only top-level dependencies (and if so, should it be only dependencies or also dev_dependencies?)

Since we are using a whitelist for now, I think that including transitive deps is okay. I do think we should update extension_discovery package to take a parameter includeTransitive in the findExtensions method though. (CC @jonasfj). We do want to include dev dependencies, IMO. For example, someone may provide a package solely for developer tooling (this package could contain a devtools extension and may promote a paired vs code extension too).