[Analyzer plugin] Only the latest version of the plugin is installed, despite the version in pubspec

[incendial]

So, long story short: somehow always the last plugin version from pub is installed no matter what version is listed in the pubspec and it installs even if dependency constraints block the update to the latest version.

Initially, I reported this issue here flutter/flutter#95092 (comment)

Another problem that people started to report the issues from the newer package version when they haven't yet updated. Like they have DCM 4.17.0, but IDE somehow reports an issue from 4.18.0. I'm not sure, if it's even possible, but it's already two reports.

but now we were able to reproduce it after I've added the version to the plugin name.

Note: the latest version in pub is exactly 4.21.2

Screenshot 1:

Screenshot 2:

Screenshot 3:

Could you please take a look? Looks like it's the last broken part from the new plugins api. Also, all the reports we received were from VS Code, so I'm not sure, that it affects IDEA.

[Hideart]

Same here. It generates very non-obvious bugs 🥲

[incendial]

@bwilkerson @scheglov could you please take a look?

[keertip]

@DanTup

[DanTup]

I'm not completely familiar with the plugin support but I had a quick look at this and was able to reproduce the issue above where a different version of the plugin compared to the pubspec was being used:

I had a look through the code for that version and found that in tools/analyzer_plugin/pubspec.yaml, v4.18.2 of the dart_code_metrics package contains this:

dependencies:
  dart_code_metrics: ^4.18.2

I found some docs about this package here, which say:

it must have a file named tools/analyzer_plugin/pubspec.yaml that can be used by the pub command to produce a .packages file describing how to resolve the package: URIs found in it. Typically, the only dependency that needs to be included is a dependency on the plugin package.

So it seems like the analyzer uses this file to set the plugin up, and that file allows for newer versions to be fetched.

What I'm not sure about is whether:

• the plugin (dart_code_metrics) should not include ^ in this file and instead have an exact version number if that's the behaviour that's expected
• the analyzer/analyzer_plugin should overwrite the version constraint with one that matches what was in the users pubspec so these things are always in-sync

This is probably a question for @bwilkerson / @scheglov (and whatever the answer is, it probably makes sense to capture in those docs).

[incendial]

@DanTup thanks for looking into that!

Yes, the version is set with ^, but it resolves to the latest version despite the dependency constrains. For example, if the package can't be updated to the analyzer 5.0.0., it still has the latest version of DCM plugin running. That's what has changed and looks like a bug (and I'm pretty sure that we were releasing new versions before and our users had never reported such issues, before the new API).

But I agree that probably Brian or Konstantin could add more about this behaviour being expected or not.

[DanTup]

but it resolves to the latest version despite the dependency constrains. For example, if the package can't be updated to the analyzer 5.0.0., it still has the latest version of DCM plugin running.

Which dependency constraints do you mean? Do you mean the analyzer/analyzer_plugin constraints in the main pubspec.yaml for dart_code_metrics are not being honoured? Or perhaps that the version of the analysis server that's running is not constraining the packages to those that use versions of analyzer/analyer_plugin that match its own? (sorry if this is a silly question, I'm not too familiar with plugins but curious to better understand these things 🙂).

[incendial]

Or perhaps that the version of the analysis server that's running is not constraining the packages to those that use versions of analyzer/analyer_plugin that match its own? (sorry if this is a silly question, I'm not too familiar with plugins but curious to better understand these things 🙂).

Yeah, that's how it has been working before. If a package lists dart_code_metrics with a ^ and a version and upgrading to an upper version is blocked (dart pub get fails), then only the plugin version from the installed dart_code_metrics is used.

Edit: actually, the plugin was just always used from the installed package.

[bwilkerson]

Yes, the version is set with ^, but it resolves to the latest version despite the dependency constrains.

My understanding of version constraints is that ^4.18.2 means that any version between 4.18.2 (inclusive) and 5.0.0 (exclusive) is allowed to match. If pub is run on the tools/analyzer_plugin/pubspec.yaml file given above, then it's valid for it to choose version 4.21.2.

For example, if the package can't be updated to the analyzer 5.0.0., it still has the latest version of DCM plugin running.

I'm a bit confused. Which package are you referring to here? (See https://github.com/dart-lang/sdk/blob/main/pkg/analyzer_plugin/doc/tutorial/package_structure.md for a description of the four possible meanings of "package" in this context.) If the below doesn't clear things up for you, you might need to restate the problem in more precise terms.

Or perhaps that the version of the analysis server that's running is not constraining the packages to those that use versions of analyzer/analyer_plugin that match its own?

The analysis server never constrains the versions of the packages used by plugins, and that's intentional.

If we shipped a version of the analysis server that was built on analyzer version 6.0.0, then any plugins that had not yet been upgraded to run on version 6.0.0 would not be able to be loaded and run. In other words, every new version of the analyzer would potentially disable some or all of the plugins being used by a given user. I think that would significantly hurt the user's experience.

Even if we did something to coordinate with plugin authors so that their plugins would all be updated before we shipped, it would mean that plugin authors couldn't provide version-specific support for their packages. (Remember that the original use case was not for a stand-alone plugin like DCM, but was for a very package-specific plugin like the one for Angular Dart, where a different version of the plugin might be needed for each new version of the host package.) If a user is using an older version of the host package, then a newer version of the plugin package might not be able to correctly support the user's code.

We therefore deemed it essential that the versions on packages used by a given plugin had to be independent of either the versions of those packages used by the analysis server or the versions used by other plugins. We achieved that goal by running each plugin in a separate isolate, making the running code completely independent of what code was being run by any other isolate.

Plugins do need to update to newer versions of the analyzer package anytime the newer version supports new language features (or the plugin is likely to break when run on a code base that's using those features), but there are no constraints for other version updates.

[incendial]

My understanding of version constraints is that ^4.18.2 means that any version between 4.18.2 (inclusive) and 5.0.0 (exclusive) is allowed to match. If pub is run on the tools/analyzer_plugin/pubspec.yaml file given above, then it's valid for it to choose version 4.21.2.

I always treated plugin and the host package as one and from this perspective update to the 4.21.2 wouldn't be possible in the target package that has DCM listed in pubspec, since the closest resolvable version is 4.18.2. Otherwise it creates a problem with the CLI and the plugin running different code.

I'm a bit confused. Which package are you referring to here? (See https://github.com/dart-lang/sdk/blob/main/pkg/analyzer_plugin/doc/tutorial/package_structure.md for a description of the four possible meanings of "package" in this context.) If the below doesn't clear things up for you, you might need to restate the problem in more precise terms.

Sorry for that, by the package I meant a target package (like a flutter app), that has DCM listed in its pubspec. If the package is unable to have 4.21.2 as a resolved dependency, but somehow has a plugin from 4.21.2 - that was not expected.

If we shipped a version of the analysis server that was built on analyzer version 6.0.0, then any plugins that had not yet been upgraded to run on version 6.0.0 would not be able to be loaded and run. In other words, every new version of the analyzer would potentially disable some or all of the plugins being used by a given user. I think that would significantly hurt the user's experience.

Even if we did something to coordinate with plugin authors so that their plugins would all be updated before we shipped, it would mean that plugin authors couldn't provide version-specific support for their packages. (Remember that the original use case was not for a stand-alone plugin like DCM, but was for a very package-specific plugin like the one for Angular Dart, where a different version of the plugin might be needed for each new version of the host package.) If a user is using an older version of the host package, then a newer version of the plugin package might not be able to correctly support the user's code.

We therefore deemed it essential that the versions on packages used by a given plugin had to be independent of either the versions of those packages used by the analysis server or the versions used by other plugins. We achieved that goal by running each plugin in a separate isolate, making the running code completely independent of what code was being run by any other isolate.

Thanks for the explanation! Then I'll release the fix removing the ^ and this should be it.

Plugins do need to update to newer versions of the analyzer package anytime the newer version supports new language features (or the plugin is likely to break when run on a code base that's using those features), but there are no constraints for other version updates.

Thats a very good point, any chance I can find a release date for new features, like patterns, records, etc. anywhere, in order to support them before they are live? Or at least an approximate date.

[bwilkerson]

... any chance I can find a release date for new features, like patterns, records, etc. ...

I don't believe that we have a firm release date. It will depend on a lot of factors including how long it takes the sub-teams (analyzer, dart2js, vm, etc.) to implement the feature. We won't ship the feature until it's solid, so we don't set a date.

I can tell you that the analyzer team has started working on records and patterns in the analyzer package. The support for records is mostly complete at this point, though the feature's spec might still change, so "complete" is a fairly vague concept at this point. :-) The work for patterns has just started, and probably isn't far enough along to be helpful.

I can also tell you that the server portion of the records work has started. We have basic support mostly finished, but are still evaluating whether there are any new fixes, assists, lints, etc. that we think should be part of the initial launch. (We often wait to see how the community will use a feature before adding stylistic lints.) The server work for patterns hasn't really started yet because the analyzer package isn't quite far enough along for that.

[incendial]

... any chance I can find a release date for new features, like patterns, records, etc. ...

I don't believe that we have a firm release date. It will depend on a lot of factors including how long it takes the sub-teams (analyzer, dart2js, vm, etc.) to implement the feature. We won't ship the feature until it's solid, so we don't set a date.

I can tell you that the analyzer team has started working on records and patterns in the analyzer package. The support for records is mostly complete at this point, though the feature's spec might still change, so "complete" is a fairly vague concept at this point. :-) The work for patterns has just started, and probably isn't far enough along to be helpful.

I can also tell you that the server portion of the records work has started. We have basic support mostly finished, but are still evaluating whether there are any new fixes, assists, lints, etc. that we think should be part of the initial launch. (We often wait to see how the community will use a feature before adding stylistic lints.) The server work for patterns hasn't really started yet because the analyzer package isn't quite far enough along for that.

Thank you so much, sounds amazing, actually. I think I've seen some references to the records, but that they're very close to be competed is great.

We often wait to see how the community will use a feature before adding stylistic lints.

Fair point, especially taking the amount of work for other features 🙂

If you have any kind of notification for the external (or internal) package maintainers, like "you can now prepare your code for the feature X", I'd be happy to receive it too 🙂

I'm closing this, thanks again for the detailed explanation.