Skip to content

Conversation

@Hweinstock
Copy link
Contributor

Problem

Follow up to: #5761 (comment)

Solution

  • remove dependency on @types/node@22 using any workaround.
  • add a tech debt test that reminds us to remove any workaround once we bump to node 18 in CI.

License: I confirm that my contribution is made under the terms of the Apache 2.0 license.

@Hweinstock Hweinstock changed the title deps(@types/node): avoid formal dependency on @types/node@22 deps(types/node): avoid formal dependency on types/node22 Oct 16, 2024
@Hweinstock Hweinstock changed the title deps(types/node): avoid formal dependency on types/node22 deps(types-node): avoid formal dependency on types-node22 Oct 16, 2024
@Hweinstock Hweinstock marked this pull request as ready for review October 16, 2024 22:38
@Hweinstock Hweinstock requested a review from a team as a code owner October 16, 2024 22:38
"webpack-merge": "^5.10.0"
},
"dependencies": {
"@types/node": "^22.7.5",
Copy link
Contributor

Choose a reason for hiding this comment

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

Does it work if this is 18 instead of 22?

I'm confused about the relationship of the copyFiles.ts scripts vs the packages/x/package.json declarations.

As an alternative to fs as any, maybe we could use the techdebt.test.ts reminder to remind us to remove this top-level dependency when the getMinNodejsVersion result is new enough?

Copy link
Contributor Author

@Hweinstock Hweinstock Oct 16, 2024

Choose a reason for hiding this comment

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

Looks like that works as well, I can update the techdebt test to match. I thought avoiding the dependency was more important than the any workaround. But I guess the version bump isn't something to worry about? Are there any other tradeoffs to consider?

Copy link
Contributor

Choose a reason for hiding this comment

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

I thought avoiding the dependency was more important than the any workaround.

Since this PR makes the total cost clearer (i.e.: small :), I'm having doubts. And also, since the risk is covered by techdebt.test.ts in either case, perhaps it's better to have type checking.

Either way is fine IMO.

Copy link
Contributor Author

@Hweinstock Hweinstock Oct 17, 2024

Choose a reason for hiding this comment

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

I think I'll keep the dependency then. Since its just a version bump (to an old stable version) and not a whole new thing, the cost seems very low. The any code doesn't read well, and could cause confusion to someone without the necessary context.

@justinmk3 justinmk3 merged commit c44fa30 into aws:master Oct 17, 2024
24 checks passed
tverney pushed a commit to tverney/aws-toolkit-vscode that referenced this pull request Oct 21, 2024
## Problem
Follow up to:
aws#5761 (comment)

## Solution
- target a version of `@types/node` that is closer to the actual version running in CI.
- add a techdebt.test.ts reminder.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants