New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Update semver usage in cdk packages #3711
Comments
I confirm this is a problem: $ cat package.json
{
"dependencies": {
"@aws-cdk/core": "1.3.0"
}
}
$ cat node_modules/\@aws-cdk/core/package.json | grep version
"version": "1.3.0"
$ cat node_modules/\@aws-cdk/cx-api/package.json | grep version
"version": "1.4.0" There is no way to downgrade to |
@statik Well technically there is... But it is a pain, I had to do it... You have first uninstall -g aws-cdk, then npm i -g aws-cdk@1.3.0. Then edit the Manually replacing 1.4.0 for 1.3.0, the after those files are updated (and commited) try again. |
@carlosrfernandez thanks for posting that workaround, but I think I speak for everyone on the team when I say that experience does not meet our CDK usability bar :( |
@skinny85 I was merely pointing out that it is possible to roll back. And in our case we had no alternative than to apply this workaround. I am in total agreement with you that the desired developer experience should be much better. |
Some implementation notes/questions below. So, I believe the correct way to model this in
If that proposal seems OK to everybody, this requires changes in the following places:
|
Just to make sure I understand the problem. It is only caused when users choose to pin their dependencies, correct? If they use a caret dependency, they should also get the latest compatible one. EDIT: I think we still have an issue with transitive dependencies. |
The main problem are transitive dependencies. Right now the contract in cdk is to use the same minor version off all packages. With a carret this semantic is violated. |
Still not good enough for intra-CDK dependencies. We might release a bug in any version (even a patch version), and with any |
Thats right, but with a bug in a bug-release another release should be easy and fast. |
The |
PR in JSII: aws/jsii#747 |
Let's research the following approach:
Reading on the spec that npm is trying to satsify: https://yarnpkg.com/blog/2018/04/18/dependencies-done-right/ |
Any updates on this issue? Inability to pin dependencies result in often conflicts at least in my team, not sure about others |
Yes, we recently switched to having a pinned dependency on the CDK-internal modules: #4470 . That should make it easier to roll back to any version that was released after that change ( |
I think this particular issue doesn't need any more work right now. Closing. |
❓ General Issue
Semver defined in internal packages.
The Question
All CDK packages use semver for internal dependencies. That means e.g.
@aws-cdk/aws-cloudfront
defines@aws-cdk/aws-iam
as dependecies with the version of itself but with a caret.E.g. version 1.2.0 of
aws-cloudfront
dependes on^1.2.0
ofaws-iam
which is wrong since it requires exaclty1.2.0
.This could easily leads to bugs which are hard to debug/understand.
The text was updated successfully, but these errors were encountered: