Inform/notify users in VS Code when a newer module version is available

[matebarabas]

Is your feature request related to a problem? Please describe.

It'd be nice to add a new feature to suggest users leveraging the latest version of a module from the Public Bicep Registry. Opening this issue is a follow up to a chat/brainstorm with @shenglol on user experience of consuming AVM modules.

Describe the solution you'd like

A possible solution in VS Code would give users a range of visual notifications when:

• a newer minor version is available (notification only visible if the user explicitly hovers over the module reference),
• a newer major version is available (visible but dimmed down notification that informs the user that a new major version is available, hence, the user might want to learn more about this version),
• multiple newer major versions are available (a clearly visible notification that states the user is multiple versions behind the latest available version).

The levels of notifications, their visibility should be configurable. The intent is to inform the users about the latest available module versions and suggest they should learn more about them and their new features.

[cedricbraekevelt]

Great request, would love to have this implemented!

[StephenWeatherford]

Issues:

• [x] Is this a linter rule or purely a UI notification?
• [x] E.g. would you get warnings on a CLI build if the rule is enabled?
• [x] Default is "Off"?
• [x] Does the list of versions available need to be live (based on most recent published versions) or should it be baked into Bicep release state (like APi versions, updated only when Bicep is released)?
  • Pros of live (probably best if not a linter rule):
    • Most recent version updates always available (if Internet)
    • Easier implementation (don't need to come up with a way to package current versions into a consumable chunk (nuget package?) during Bicep build process)
  • Pros of non-live (probably best if a linter rule):
    • If a linter rule, CLI build results will be consistent between machines, connectivity, and caching states
    • If a linter rule, will get warnings even if no Internet connectivity
• [x] Fixes available?
• [x] How much customization does it need?
  • [x] Major/minor updates?
  • [x] Time window like API Versions rule? Follow above suggestion of more noise if multiple versions behind?

[StephenWeatherford]

Decisions so far:

• It is a linter rule
• Defaults to "off" (like use-recent-api-versions)
• It should use "live" data (2-3-day cache), not dependent on Bicep release to update
• Ideally this should be baked into the module restore process, so that data is downloaded during module restore and not during the run of the actual rule
• Specifically --no-restore should also keep this rule from downloading data
• Need configuration to specify behavior if the cache is missing or errored out (should default to same diagnostic config as the rule itself) - e.g. if rule set to "Error" and no cache available, should give an error output. But can be configured to only give "info" or be "off" for this scenario. (Do we currently allow this?)
• Need configuration as to how far behind (timeframe or major/minor) allowed before the rule fails
• Do we need different diagnostic levels for minor updates available vs major updates available?
• Consider: can this work for private ACRs? Do we even need an index?

[StephenWeatherford]

Issues:

• [ ] Downloading the data during module restore will increase module restore cost if there is no cache. I think it's only one ACR call, though (for private) and could be one http GET for public modules.
• [ ] There's no specified format for module tags, so we either need a way to restrict the formats we allow or a way to specify a regex or something to extract the format. E.g. "v1", "v1-preview", "v1.0.2", "1.0.2", "1.0.20-beta" etc.
• [ ] If we get tags in order of publish date (not sure we do), we could go by how many versions behind, period.
• [ ] Can we always use semantic version comparisons? E.g. "v1" is lower than "v1.2"?
• [ ] Probably should only do a version comparison (e.g. "complain if the module is two or more minor versions behind", not a date comparison (e.g. rule can't say "complain if there's a newer version and it's been published for at least two months). This is because I think getting the date of publishing would require an extra ACR call on the tag. Getting all tags is a single call.

[jtracey93]

We should be able to rely upon semantic versioning here for comparisons as we cannot update an existing version in the MCR without a lot of manual work, so we actually prevent this in the CI.

The CI also guarantees the formatting of the tags etc.