(alpha modules): modify semver tagging pattern to allow for ranges

[timcosta]

Describe the feature

Hi all! The alpha modules are currently tagged like @aws-cdk/aws-redshift-alpha@2.18.0-alpha.0. This is presenting a problem because it's impossible to set up a peer dependency for an alpha module that doesn't require an exact version match.

I am suggesting that #15581 be re-discussed in order to make the alpha modules usable in libraries, which they currently are not unless you ensure all consumers and other consumed libraries use the exact same version in their peer dependencies.

Use Case

We are consuming multiple vended libraries that set peer dependencies on @aws-cdk/aws-redshift-alpha, one set to ^2.18.0-alpha.0 and the other set to ^2.44.0-alpha.0. While it would be logical at first glance for 2.44.0-alpha.0 to satisfy ^2.18.0-alpha.0, due to how semver handles prerelease which you can test out here to verify the issue i am referring to.

It is not currently possible to include two libraries with peer dependencies on the same CDK alpha module, unless the dependencies match exactly.

Proposed Solution

I suggest that the -alpha.0 be dropped altogether, because the package name already specifies that its an alpha package. Having it in the version as well makes it seem like its an alpha release of an alpha package when these versions are the ones that are meant to be consumed, and is creating a lot of issues with peerDependencies when packages vend constructs that rely on alpha constructs.

Here's an example in cdk-monitoring-constructs of what i mean.

Other Information

This seems to have been a fun side effect of NPM v7 unfortunately, where it now "will block installations if an upstream dependency conflict is present that cannot be automatically resolved".

It appears that the decision in #15581 was to use 2.x.y-alpha as the structure, but when implemented the .0 was also added in #16043 which led to additional undesirable behavior when NPM v7 was thrown into the mix.

Acknowledgements

• I may be able to implement this feature request
• This feature might incur a breaking change

CDK version used

2.56.0

Environment details (OS name and version, etc.)

macos 13, m1, node 16, npm 8

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.

[cgatt]

Seconding this issue. The lockstep versioning of the alpha modules makes managing peer dependencies virtually impossible, as semvar ranges cannot be defined.
#15581 highlights that it's important that it be clear the alpha packages are intended for cdkv2, but this can be done with naming - i.e. @aws-cdk/aws-lambda-python-alpha-v2 - rather than versioning, if still required now that CDK v1 is deprecated.
Following the 0.x.y versioning pattern will drastically improve the ability of CDK alpha modules to be used in libraries, especially JSII libraries where extending the interfaces of the alpha libraries means working around the peer dependency versioning issue with bundling is impossible (as JSII libraries can not export interfaces from bundled dependencies).

[jesterhazy]

+1 this is extremely frustrating for anyone providing a construct library and for their downstream users

[otaviomacedo]

Alpha modules are experimental, so any version can introduce breaking changes. This versioning scheme was chosen specifucally to prevent accidental updates that break your code, and which are very hard to debug ("undefined is not a function" type errors).

If you know what you're doing, you can pick your own correct version of the alpha module in your package.json, install with npm install --legacy-peer-deps, which tells NPM to revert to the old way (before v7) of handling peer dependencies.

In any case, we don't recommend library authors to depend on alpha modules.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.
If you wish to keep having a conversation with other community members under this issue feel free to do so.