chore(cli): explicit defaults to yargs definition and cli arguments#32596
chore(cli): explicit defaults to yargs definition and cli arguments#32596mergify[bot] merged 15 commits intomainfrom
Conversation
aws-cdk-automation
left a comment
There was a problem hiding this comment.
The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.
A comment requesting an exemption should contain the text Exemption Request. Additionally, if clarification is needed add Clarification Request to a comment.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #32596 +/- ##
=======================================
Coverage 80.64% 80.64%
=======================================
Files 107 107
Lines 6996 6996
Branches 1290 1290
=======================================
Hits 5642 5642
Misses 1175 1175
Partials 179 179
Flags with carried forward coverage won't be shown. Click here to find out more.
|
| // GENERATED FROM packages/aws-cdk/lib/config.ts. | ||
| // Do not edit by hand; all changes will be overwritten at build time from the config file. | ||
| // ------------------------------------------------------------------------------------------- | ||
| /* eslint-disable @stylistic/comma-dangle, @stylistic/comma-spacing, @stylistic/max-len, @stylistic/quotes, @stylistic/quote-props */ |
There was a problem hiding this comment.
We don't have to do it for this pr but in the future can we keep non-functional changes in a separate pr. It makes it a bit difficult to review when they're mixed together
There was a problem hiding this comment.
while in principle you are right i don't think that the linter changes really affect your reading of the diff in this file. imo this is about leaving the codebase better than when you found it, and i'd rather not have to try to remember to do it retroactively especially for something as small as this. i think its a judgement call, and my judgement here is that i'd rather include it in this PR than give myself additional busy work. but if you feel differently i will move it to a different PR.
There was a problem hiding this comment.
It's not a major impact for this pr but it's a bad habit to have. Mixing non-functional and functional changes in the same pr was a callout for the v3 migration regressions story as well.
There was a problem hiding this comment.
But yeah, fine here. Just lets try to avoid this in the future
| return String(defaultValue); | ||
| function normalizeDefault(defaultValue: any, type: string): string { | ||
| const validDefaults = ['boolean', 'string', 'number', 'object']; | ||
| if (validDefaults.includes(typeof defaultValue)) { |
There was a problem hiding this comment.
99% sure typeof default here isn't nullsafe since the type of null is 'object' in typescript https://dev.to/_ravo_lution/why-typeof-null-is-object-181
We should make sure this is null/undefined safe.
There was a problem hiding this comment.
JSON.stringify(null) = 'null' which seems reasonable to me. I also don't think there's any way that defaultValue actually is null.
| parser: 'typescript', | ||
| printWidth: 150, | ||
| singleQuote: true, | ||
| trailingComma: 'all', |
There was a problem hiding this comment.
same comment as above that I'd prefer these be in seperate prs so we're not crossing the streams but it's fine for now
| * Add contextual string parameter (KEY=VALUE) | ||
| * | ||
| * @default - undefined | ||
| * @default - [] |
There was a problem hiding this comment.
There's a function somewhere that defines rules for array options:
- undefined => not provided
- empty array => deliberately an empty list
That might be why your tests are failing.
There was a problem hiding this comment.
yep. I changed the default to [] because providing undefined was also causing problems. elsewhere we are expecting the context field to at least exist, which it doesn't if we default to undefined. I know why this is happening, but still thinking through what the best path forward is.
There was a problem hiding this comment.
this PR is not meant to change any functionality. since yargs normally defaults to undefined, even for arrays, I will update this PR to reflect that and fix the unit tests that are failing in that case.
There was a problem hiding this comment.
ok i got to the bottom of this and essentially this bug in yargs is the problem: yargs/yargs#2443
i'm back to defaulting arrays as [], except for notification-arns which should be defaulted to undefined, but right now that leads to notification-arns being [undefined].
going forward, it should be the case that unless otherwise specified, arrays are defaulted as []
| * Name or path of a node package that extend the CDK features. Can be specified multiple times | ||
| * | ||
| * @default - undefined | ||
| * @default - [] |
There was a problem hiding this comment.
arrays now default to []
| * The action (or sub-action) you want to perform. Valid entires are "print", "tag", "delete-tagged", "full". | ||
| * | ||
| * @default - full | ||
| * @default - "full" |
There was a problem hiding this comment.
this represents an improvement for string defaults
| * Delete assets that have been marked as isolated for this many days | ||
| * | ||
| * @default - undefined | ||
| * @default - 0 |
There was a problem hiding this comment.
this fixes a bug where numbers did not render the right default
| * Additional parameters passed to CloudFormation at deploy time (STACK:KEY=VALUE) | ||
| * | ||
| * @default - undefined | ||
| * @default - {} |
There was a problem hiding this comment.
this is probably a bug in config. either way i will look at it in a separate PR
| // prevents us from doing so. This should be changed if the issue is resolved. | ||
| ...(option === 'notification-arns' ? {} : { default: generateDefault(options[option].type) }), | ||
| ...options[option], | ||
| }; |
There was a problem hiding this comment.
yargs/yargs#2443 -> this issue prevents me from specifying and undefined default
aws-cdk/packages/aws-cdk/lib/cdk-toolkit.ts
Lines 374 to 378 in 61626dc
notification-arns is a special case.
so we have notification-arns defaulting to undefined and other arrays defaulting to []. the yargs issue is why i cannot currently default to undefined, as yargs inexplicably turns that into [undefined].
|
➡️ PR build request submitted to A maintainer must now check the pipeline and add the |
✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.
| case 'string': | ||
| case 'number': | ||
| case 'object': | ||
| return JSON.stringify(defaultValue); |
There was a problem hiding this comment.
Evaluating nulls as 'object' still feels wrong to me but whatever I don't think it'd ever be a problem
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
AWS CodeBuild CI Report
Powered by github-codebuild-logs, available on the AWS Serverless Application Repository |
|
Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork). |
|
Comments on closed issues and PRs are hard for our team to see. |
This makes sure we have a default value (even if its
undefined) for every option in yargs. There is a special case for arrays where the default will be[].I also took the liberty to simplify the eslint exemptions by changing the prettier options.
Checklist
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license