-
Notifications
You must be signed in to change notification settings - Fork 60
chore: use non-caret dependency versions #246
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
Conversation
|
I'm just worried this will affect the release process, read: bump and unbump and if the repo is considered unchanged afterwards. |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #246 +/- ##
==========================================
- Coverage 85.03% 85.03% -0.01%
==========================================
Files 206 218 +12
Lines 35202 36530 +1328
Branches 4533 4569 +36
==========================================
+ Hits 29934 31062 +1128
- Misses 5116 5318 +202
+ Partials 152 150 -2
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
.projenrc.ts
Outdated
| cloudAssemblySchema.customizeReference({ exactVersion: true }), | ||
| cloudFormationDiff.customizeReference({ exactVersion: true }), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not right. Toolkit Library intentionally uses dependency ranges. In fact it should probably be wider and declare the actual minimal version and not just ^current.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll happily roll these back to carets, but I don't think it makes sense to use lower versions than current.
- For a fresh install:
^xwill use the highest possible version greater thanx. It doesn't matter if we write^xor^y, ifyis available it will be installed. - For an
npm upgrade: by default it will upgrade everything, so same scenario as fresh install. - For an
npm upgrade toolkit-only: the use case is that a user wants a new version of the toolkit, but explicitly wants to hold back versions of dependency packages? Do we think that is realistic?
f995133 to
32c0b68
Compare
15c1395 to
6a01f80
Compare
(Stacked PR on top of #246) --- By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license
a792b5c to
6a01f80
Compare
6a01f80 to
794c0d8
Compare
794c0d8 to
f9df8bf
Compare
Monorepo dependencies were using carets `^`; for most of these it didn't matter because the resulting artifact was bundled anyway, but for a couple it did matter: * `cdk -> aws-cdk`: should use the exact same version, otherwise running `npx cdk@2.1000` may accidentally execute `aws-cdk@2.1001`.
f9df8bf to
4ea903f
Compare
This adds in the code for `@aws-cdk/integ-runner`, which is being removed from the original `aws-cdk` repository here: aws/aws-cdk#33835 Process: * The removal PR should be merged first * Then this should be merged * Then we need to find [the latest released version](https://www.npmjs.com/package/@aws-cdk/integ-runner) and add a tag named `@aws-cdk/integ-runner@v2.185.0` (or whatever the latest version is) on the parent commit of this commit. This proposed to drop the `-alpha` release tag of this package, which seems fine. We've been running this for years, it hasn't changed much, and future updates will be easier to consume if we drop the prerelease tags. (Stacked PR on top of #246) --- By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license --------- Signed-off-by: github-actions <github-actions@github.com> Co-authored-by: github-actions <github-actions@github.com>
Monorepo dependencies were using carets
^; for most of these it didn't matter because the resulting artifact was bundled anyway, but for at least one it does matter:cdk -> aws-cdk: should use the exact same version, otherwise runningnpx cdk@2.1000may accidentally executeaws-cdk@2.1001.Also making the
cloud-assembly-schemareferences exact; probably doesn't matter since we're bundling most of these but it does show the intention of shipping exactly one version.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license