Skip to content
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.

Sign up for GitHub

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

Jump to bottom

(aws-cdk-lib): npm install aws-cdk-lib doesn't bring the latest alpha release #13058

Closed
eladb opened this issue Feb 15, 2021 · 6 comments
Closed

(aws-cdk-lib): npm install aws-cdk-lib doesn't bring the latest alpha release #13058

eladb opened this issue Feb 15, 2021 · 6 comments
Assignees
@njlynch
Labels
aws-cdk-lib Related to the aws-cdk-lib package bug This issue is a bug. effort/small Small work item – less than a day of effort p1

Comments

@eladb
Copy link
Contributor

eladb commented Feb 15, 2021

When running npm install aws-cdk-lib, users get the last published module into the latest dist-tag, which is currently 2.0.0-alpha.0, while the next dist-tag includes the actual latest.

Since aws-cdk-lib is a new module, I think we should publish our alpha releases under the latest dist-tag in order to allow early adopters to install the correct version. There is no notion of "next" for aws-cdk-lib yet. When we prepare CDK v3.0, it will make sense to publish it under the @next dist-tag since at that point @latest will refer to the stable v2.x line.

Reproduction Steps

npm instal aws-cdk-lib

What did you expect to happen?

I expected v2.0.0-alpha.4.

What actually happened?

I got v2.0.0-alpha.0.

Other

Output of npm view aws-cdk-lib:

aws-cdk-lib@2.0.0-alpha.0 | Apache-2.0 | deps: 9 | versions: 5
The AWS Cloud Development Kit library
https://github.com/aws/aws-cdk

keywords: aws, cdk

dist
.tarball: https://registry.npmjs.org/aws-cdk-lib/-/aws-cdk-lib-2.0.0-alpha.0.tgz
.shasum: 70def4619e8bc4250da7d569ca87871de08117be
.integrity: sha512-8gG8gbazCVJPYbS7bwadJyEsRAGfdWr5jlqiw3DS7yTzXGCwufc5DMmTv89pEO3KTdO9naIAND+T58n3f9MFEg==
.unpackedSize: 105.3 MB

dependencies:
@balena/dockerignore: ^1.0.2 fs-extra: ^9.0.1             jsonschema: ^1.4.0           punycode: ^2.1.1             yaml: 1.10.0
case: 1.6.3                  ignore: ^5.1.8               minimatch: ^3.0.4            semver: ^7.3.2

maintainers:
- aws-cdk-team <aws-cdk-dev@amazon.com>

dist-tags:
latest: 2.0.0-alpha.0      next: 2.0.0-alpha.4        preview-v2: 2.0.0-alpha.0

This is 🐛 Bug Report
@eladb eladb added bug This issue is a bug. needs-triage This issue or PR still needs to be triaged. labels Feb 15, 2021
@github-actions github-actions bot added the aws-cdk-lib Related to the aws-cdk-lib package label Feb 15, 2021
@nija-at nija-at added effort/small Small work item – less than a day of effort p1 and removed needs-triage This issue or PR still needs to be triaged. labels Feb 16, 2021
@nija-at
Copy link
Contributor

nija-at commented Feb 16, 2021 •
edited
Loading

We've misjudged the tagging work here. We should probably drop 'next' here and just go back to using 'latest'.

However, other packages we publish like @aws-cdk/cx-api, etc. that must not take on the 'latest' tag.

@njlynch njlynch assigned njlynch and unassigned nija-at Feb 16, 2021
@njlynch
Copy link
Contributor

njlynch commented Feb 16, 2021

Really, using latest only makes sense for aws-cdk-lib; for all the others we publish (e.g., @aws-cdk/cx-api, @aws-cdk/cloudformation-diff) continuing with the existing strategy is probably ok.

Proposal:

  1. Add a npmdisttag property to the aws-cdk-lib package.json with a value of "latest".
  2. Alter the NPM publishing job to use any npmdisttag value present as an override to the current disttag value.
  3. Remove the preview-v2 disttag from all published versions; the presence of this disttag is likely to cause confusion and provides no value.

Thoughts?

@eladb
Copy link
Contributor Author

eladb commented Feb 16, 2021

Sounds good. Bear in mind that npm already has support for specifying publishConfig but I think our publishers ignore it.

@nija-at
Copy link
Contributor

nija-at commented Feb 16, 2021 •
edited
Loading

Can we use the npmdisttag property in package.json across all of our v2 packages? Keep it consistent.

And drop this in both branches -

aws-cdk/release.json

Line 4 in 355fed8

"distTag": "latest"

@eladb
Copy link
Contributor Author

eladb commented Feb 16, 2021

We could, but then i would require this field in all package.json files to make sure we don't accidentally publish latest.

njlynch added a commit that referenced this issue Feb 17, 2021
@njlynch
chore: make NPM dist tag explicit for all packages
9a8ef0c 
Currently, our NPM tag strategy is uniform across all packages. This _mostly_
works, but for V2 it makes sense for `aws-cdk-lib` to be published with a dist
tag of 'latest' while still publishing all of the other libraries as 'next'.

This change is the first supporting change to enable us to have different dist
tags for different packages.
* Introduces a new pkglint rule that enforces that each package.json has a
  publishConfig and tag. For v1, this defaults to 'latest'; for v2 it will
  default to 'next'. These are the correct values, except for `aws-cdk-lib`,
  which will need to be manually changed to `latest`.
* Removes the disttag element from `release.json`.
* Changing `check-api-compatibility` to use the dist tags from  the individual
  `package.json` files, rather than from `release.json`.

Once this is approved, and merged up to V2, the change to flip the aws-cdk-lib
tag can be made. Finally, we will update our publishing infrastructure so these
new tags are respected.

related #13058
njlynch added a commit that referenced this issue Feb 17, 2021
@njlynch
chore: make NPM dist tag explicit for all packages
21b03f5 
Currently, our NPM tag strategy is uniform across all packages. This _mostly_
works, but for V2 it makes sense for `aws-cdk-lib` to be published with a dist
tag of 'latest' while still publishing all of the other libraries as 'next'.

This change is the first supporting change to enable us to have different dist
tags for different packages.
* Introduces a new pkglint rule that enforces that each package.json has a
  publishConfig and tag. For v1, this defaults to 'latest'; for v2 it will
  default to 'next'. These are the correct values, except for `aws-cdk-lib`,
  which will need to be manually changed to `latest`.
* Removes the disttag element from `release.json`.
* Changing `check-api-compatibility` to use the dist tags from  the individual
  `package.json` files, rather than from `release.json`.

Files to look at (all others are package.json changes):
* release.json
* scripts/check-api-compatibility.sh
* scripts/resolve-version-lib.js
* scripts/script-tests/resolve-version.test.js
* tools/pkglint/lib/rules.ts

Once this is approved, and merged up to V2, the change to flip the aws-cdk-lib
tag can be made. Finally, we will update our publishing infrastructure so these
new tags are respected.

related #13058
@njlynch njlynch mentioned this issue Feb 17, 2021
Merged
mergify bot pushed a commit that referenced this issue Feb 17, 2021
@njlynch
chore: make NPM dist tag explicit for all packages (#13109)
d183af2 
Currently, our NPM tag strategy is uniform across all packages. This _mostly_
works, but for V2 it makes sense for `aws-cdk-lib` to be published with a dist
tag of 'latest' while still publishing all of the other libraries as 'next'.

This change is the first supporting change to enable us to have different dist
tags for different packages.
* Introduces a new pkglint rule that enforces that each package.json has a
  publishConfig and tag. For v1, this defaults to 'latest'; for v2 it will
  default to 'next'. These are the correct values, except for `aws-cdk-lib`,
  which will need to be manually changed to `latest`.
* Removes the disttag element from `release.json`.
* Changing `check-api-compatibility` to use the dist tags from  the individual
  `package.json` files, rather than from `release.json`.

Files to look at (all others are package.json changes):
* release.json
* scripts/check-api-compatibility.sh
* scripts/resolve-version-lib.js
* scripts/script-tests/resolve-version.test.js
* tools/pkglint/lib/rules.ts

Once this is approved, and merged up to V2, the change to flip the aws-cdk-lib
tag can be made. Finally, we will update our publishing infrastructure so these
new tags are respected.

related #13058


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
NovakGu pushed a commit to NovakGu/aws-cdk that referenced this issue Feb 18, 2021
@njlynch @NovakGu
chore: make NPM dist tag explicit for all packages (aws#13109)
5f981c7 
Currently, our NPM tag strategy is uniform across all packages. This _mostly_
works, but for V2 it makes sense for `aws-cdk-lib` to be published with a dist
tag of 'latest' while still publishing all of the other libraries as 'next'.

This change is the first supporting change to enable us to have different dist
tags for different packages.
* Introduces a new pkglint rule that enforces that each package.json has a
  publishConfig and tag. For v1, this defaults to 'latest'; for v2 it will
  default to 'next'. These are the correct values, except for `aws-cdk-lib`,
  which will need to be manually changed to `latest`.
* Removes the disttag element from `release.json`.
* Changing `check-api-compatibility` to use the dist tags from  the individual
  `package.json` files, rather than from `release.json`.

Files to look at (all others are package.json changes):
* release.json
* scripts/check-api-compatibility.sh
* scripts/resolve-version-lib.js
* scripts/script-tests/resolve-version.test.js
* tools/pkglint/lib/rules.ts

Once this is approved, and merged up to V2, the change to flip the aws-cdk-lib
tag can be made. Finally, we will update our publishing infrastructure so these
new tags are respected.

related aws#13058


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
eladb pushed a commit that referenced this issue Feb 22, 2021
@njlynch
chore: make NPM dist tag explicit for all packages (#13109)
212775e 
Currently, our NPM tag strategy is uniform across all packages. This _mostly_
works, but for V2 it makes sense for `aws-cdk-lib` to be published with a dist
tag of 'latest' while still publishing all of the other libraries as 'next'.

This change is the first supporting change to enable us to have different dist
tags for different packages.
* Introduces a new pkglint rule that enforces that each package.json has a
  publishConfig and tag. For v1, this defaults to 'latest'; for v2 it will
  default to 'next'. These are the correct values, except for `aws-cdk-lib`,
  which will need to be manually changed to `latest`.
* Removes the disttag element from `release.json`.
* Changing `check-api-compatibility` to use the dist tags from  the individual
  `package.json` files, rather than from `release.json`.

Files to look at (all others are package.json changes):
* release.json
* scripts/check-api-compatibility.sh
* scripts/resolve-version-lib.js
* scripts/script-tests/resolve-version.test.js
* tools/pkglint/lib/rules.ts

Once this is approved, and merged up to V2, the change to flip the aws-cdk-lib
tag can be made. Finally, we will update our publishing infrastructure so these
new tags are respected.

related #13058


----

*By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@njlynch njlynch closed this as completed Feb 22, 2021
@github-actions
Copy link

⚠️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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@njlynch njlynch

Labels
aws-cdk-lib Related to the aws-cdk-lib package bug This issue is a bug. effort/small Small work item – less than a day of effort p1
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@eladb @njlynch @nija-at