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.

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

chore(cli): explicit defaults to yargs definition and cli arguments #32596

Open
wants to merge 14 commits into
base: main
Choose a base branch
from

Conversation

kaizencc
Copy link
Contributor

@kaizencc kaizencc commented Dec 19, 2024

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

@kaizencc kaizencc requested a review from a team as a code owner December 19, 2024 21:48
@github-actions github-actions bot added the p2 label Dec 19, 2024
@aws-cdk-automation aws-cdk-automation requested a review from a team December 19, 2024 21:48
@mergify mergify bot added the contribution/core This is a PR that came from AWS. label Dec 19, 2024
Copy link
Collaborator

@aws-cdk-automation aws-cdk-automation left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

@aws-cdk-automation aws-cdk-automation added the pr/needs-cli-test-run This PR needs CLI tests run against it. label Dec 19, 2024
Copy link

codecov bot commented Dec 19, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 80.64%. Comparing base (61626dc) to head (2702326).
Report is 3 commits behind head on main.

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           
Flag Coverage Δ
suite.unit 80.64% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Components Coverage Δ
packages/aws-cdk 80.64% <ø> (ø)

@kaizencc kaizencc changed the title chore(cli): add explicit defaults to yargs definition chore(cli): explicit defaults to yargs definition and cli arguments Dec 23, 2024
@@ -2,7 +2,7 @@
// 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 */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

tools/@aws-cdk/cli-args-gen/lib/cli-type-gen.ts Outdated Show resolved Hide resolved
return String(defaultValue);
function normalizeDefault(defaultValue: any, type: string): string {
const validDefaults = ['boolean', 'string', 'number', 'object'];
if (validDefaults.includes(typeof defaultValue)) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JSON.stringify(null) = 'null' which seems reasonable to me. I also don't think there's any way that defaultValue actually is null.

}).render(scope);

return prettier.format(ts, {
parser: 'typescript',
printWidth: 150,
singleQuote: true,
trailingComma: 'all',
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

tools/@aws-cdk/cli-args-gen/lib/cli-type-gen.ts Outdated Show resolved Hide resolved
@@ -143,14 +143,14 @@ export interface GlobalOptions {
/**
* Add contextual string parameter (KEY=VALUE)
*
* @default - undefined
* @default - []
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 []

*/
readonly context?: Array<string>;

/**
* Name or path of a node package that extend the CDK features. Can be specified multiple times
*
* @default - undefined
* @default - []
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

arrays now default to []

@@ -515,28 +515,28 @@ export interface GcOptions {
/**
* The action (or sub-action) you want to perform. Valid entires are "print", "tag", "delete-tagged", "full".
*
* @default - full
* @default - "full"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this represents an improvement for string defaults

*/
readonly type?: string;

/**
* Delete assets that have been marked as isolated for this many days
*
* @default - undefined
* @default - 0
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this fixes a bug where numbers did not render the right default

@@ -645,7 +645,7 @@ export interface DeployOptions {
/**
* Additional parameters passed to CloudFormation at deploy time (STACK:KEY=VALUE)
*
* @default - undefined
* @default - {}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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],
};
Copy link
Contributor Author

@kaizencc kaizencc Dec 24, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yargs/yargs#2443 -> this issue prevents me from specifying and undefined default

// Following are the same semantics we apply with respect to Notification ARNs (dictated by the SDK)
//
// - undefined => cdk ignores it, as if it wasn't supported (allows external management).
// - []: => cdk manages it, and the user wants to wipe it out.
// - ['arn-1'] => cdk manages it, and the user wants to set it to ['arn-1'].
-> this is relevant for why 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].

@kaizencc kaizencc deployed to test-pipeline December 24, 2024 21:49 — with GitHub Actions Active
@aws-cdk-automation
Copy link
Collaborator

➡️ PR build request submitted to test-main-pipeline ⬅️

A maintainer must now check the pipeline and add the pr-linter/cli-integ-tested label once the pipeline succeeds.

@aws-cdk-automation
Copy link
Collaborator

AWS CodeBuild CI Report

  • CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
  • Commit ID: 2702326
  • Result: SUCCEEDED
  • Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

@kaizencc kaizencc added pr-linter/cli-integ-tested Assert that any CLI changes have been integ tested and removed pr/needs-cli-test-run This PR needs CLI tests run against it. labels Dec 25, 2024
@kaizencc kaizencc requested a review from HBobertz December 25, 2024 00:51
@aws-cdk-automation aws-cdk-automation dismissed their stale review December 25, 2024 00:53

✅ Updated pull request passes all PRLinter validations. Dismissing previous PRLinter review.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
contribution/core This is a PR that came from AWS. p2 pr-linter/cli-integ-tested Assert that any CLI changes have been integ tested
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants