data-service-generator versions and plugin versions

[overbit]

The Problem: Plugins

With the new data-service-generator versioning, amplication would be able to support older version of the generator with newer version of the platform.
This will mean that plugins might run against different versions of the data-service-generator and not against the most recent code.

TL;DR

This problem is similar to the npm plugins dependencies problem (https://nodejs.org/en/blog/npm/peer-dependencies) and the solution I'm proposing is following the same pattern: peerDependencies!

The Solution:

In order to maintain both great and clear user experience for the final user and facilitate plugin development, the solution will span on two main changes:

1. Enrich the plugin settings schema with a mandatory peerDependency object. Similarly to the package.json peerDependencies, this object will list pairs of "dependency-name" : "version" where version can be in format of specific version or using ^ operator to define the support to any minor version. The list of peerDependencies will include any peer plugin as well as code-generator dependency representing the codeGeneratorVersion (generic name for data-service-generator)
2. Enrich the dsgContext with a new property codeGeneratorVersion that will allow plugins to support different versions of data-service-generator in the same version. Plugins will not be forced to support old versions

Additional changes:

3. build log to show a warning if an installed plugin peerDependencies are not respected (wrong versions or missing dependency)
4. [optional] plugin catalog to show a warning if peerDependencies are not respected (wrong versions or missing dependency)

i.e.
plugin-spaghetti is developed to be able to support (work with) version v2.0.0+ of the data-service-generator and it will need another plugin @amplication/plugin-auth-core to be installed in the service to properly work.
Apart from the code changes that might leverage the codeGeneratorVersion value in the DsgContext, the plugin will be bundled and published with the following settings:

// .amplicationrc.json
{
  "peerDependencies" : {
    "code-generator": "^2.0.0",
    "@amplication/plugin-auth-core" : "^1.0.0"
  },
  "settings": {},
  "systemSettings": {
    "requireAuthenticationEntity": "false"
  }
}

Observation: the additional benefit of this approach is that it will allow us to support/solve dependencies between plugins (not currently supported)

[overbit]

More details: currently only 10 projects out of more the 24k are using fixed plugins version

[barshimi]

I suggest handle this issue in a different way. By concept, plugins should be decoupled from DSG engine. it means that plugin can change/add files/text to final generated code even if the end results is not a valid/working results. If we agree about that, it will allow us to ignore the progress of the engine vs the changes in plugins. The user will be responsible for his final results and make sure it works. we should maintain the isolation between the engine and the plugins. we can help the user to avoid code issue by notification mechanism and not managing the rules.
This will give us two things: first, keep the simplicity and independency of plugin mechanism. this is important for future growth. second, it will prevent the need to develop a special mechanism for managing gaps between the two systems, plugin & DSG.

I suggest to handle it in two ways:

1. add indication to each plugin with its compatible DSG version. this should be part of the plugin develop and will add a key for each plugin version that reflect the DSG version.
2. create an alert mechanism on client that notify the user about issues that can be aroused. it wont disabled user decision, but advise him to change the selection to get harmonies code.

[overbit]

I think we might mean the same thing here with different wording

Enrich the plugin settings schema with a mandatory peerDependency object. Similarly to the package.json peerDependencies, this object will list pairs of "dependency-name" : "version" where version can be in format of specific version or using ^ operator to define the support to any minor version. The list of peerDependencies will include any peer plugin as well as code-generator dependency representing the codeGeneratorVersion (generic name for data-service-generator)