Skip to content

Conversation

@Hweinstock
Copy link
Contributor

@Hweinstock Hweinstock commented Oct 9, 2024

Problem

(title)

Solution

Based on answer here: https://stackoverflow.com/questions/13786160/copy-folder-recursively-in-node-js we can use cp. This assumes node v16.7.0+.
Note that overwrite is now force based on https://nodejs.org/api/fs.html#fscpsyncsrc-dest-options

For this to work, we must bump the dependency @types/node. Currently bumped to latest, but can try to test earliest version that works if that would be desirable.


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

@Hweinstock
Copy link
Contributor Author

I'm tempted to consolidate the shared logic among copyFiles somewhere, but its spanning across the extensions. Is it worth leaving it as duplicated code to avoid cross-extension imports?

@justinmk3
Copy link
Contributor

justinmk3 commented Oct 10, 2024

Needed to add --experimental-modules flag to node runtime for it to work in CI. Added a tech debt test to remove this once its not longer experimental.

👍 there might be way to enable that flag only for the npm package.json copyFiles task.

I'm tempted to consolidate the shared logic among copyFiles somewhere, but its spanning across the extensions. Is it worth leaving it as duplicated code to avoid cross-extension imports?

It's worth creating a tracking issue but might involve some tradeoffs, so better to skip it for now.

@Hweinstock
Copy link
Contributor Author

Unfortunately the flag didn't make it work in CI, removed the outdated piece in the description.

@justinmk3
Copy link
Contributor

TSError: ⨯ Unable to compile TypeScript:
Error: scripts/build/copyFiles.ts(108,12): error TS2339: Property 'cpSync' does not exist on type 'typeof import("fs")'.

/Users/runner/runners/2.320.0/externals/node20/bin/node: --experimental-fs is not allowed in NODE_OPTIONS

yeah I don't see a relevant flag at https://nodejs.org/dist/latest-v16.x/docs/api/cli.html#cli_node_options_options

A way to check different node versions is to use https://github.com/nvm-sh/nvm and then try fs.cpSync on 16/18/20.

@Hweinstock
Copy link
Contributor Author

Yeah I used nvm to downgrade it locally to the same in CI, and it started working. Still unsure what it is about CI that makes it different.

@justinmk3
Copy link
Contributor

justinmk3 commented Oct 14, 2024

Still unsure what it is about CI that makes it different.

Let's try bumping GHA CI to node 18 (or start with 22 and work backwards):

If node 18 works, we can use that in all CI. Or even newer. There's no real reason why the node used in CI needs to match the node shipped with vscode; the vscode-shipped node will be used to execute the actual test code.

@Hweinstock
Copy link
Contributor Author

I made @types/node a direct dependency, which I believe consequently bumped its version and fixed the error.

@Hweinstock Hweinstock marked this pull request as ready for review October 16, 2024 15:50
@Hweinstock Hweinstock requested a review from a team as a code owner October 16, 2024 15:50

try {
await fs.copy(src, dst, {
fs.cpSync(src, dst, {
Copy link
Contributor

Choose a reason for hiding this comment

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

We could avoid the formal dependency on @types/node@22 by casting this to any. We normally wouldn't do that, but it may be fine in this case because it avoids confusion, since our packages/ depend on @types/node@16 (and that's intentional because vscode ships with node 16).

We can add a check to techdebt.test.ts to remind us to revisit this when we bump to node 18:

it('nodejs minimum version', async function () {
const minNodejs = env.getMinNodejsVersion()
// XXX: available since node 16, but not sure how much work this will be, yet.
assert.ok(
semver.lt(minNodejs, '18.0.0'),

Suggested change
fs.cpSync(src, dst, {
(fs as any).cpSync(src, dst, {

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I see, so once we update to 18, we will have @types/node@18 which should allow us to remove the any?

Also, tracking as a follow-up.

function main() {
try {
await Promise.all(tasks.map(copy))
tasks.map(copy)
Copy link
Contributor

Choose a reason for hiding this comment

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

It's a bit surprising that we were running copy tasks in parallel. I doubt that gives much of a speedup, and it makes the logs less readable, and it could lead to weird races. I think this is better now.

@justinmk3
Copy link
Contributor

justinmk3 commented Oct 16, 2024

Nice! Can we remove fs-extra now? Or could be a followup.

npm uninstall --save '@types/fs-extra' 'fs-extra' -w packages/core/

@justinmk3 justinmk3 merged commit 5cbe42b into aws:master Oct 16, 2024
31 of 34 checks passed
@justinmk3
Copy link
Contributor

Merged. Let's do the above comments as a followup, that way if there are any problems it's easy to revert or drop.

@Hweinstock Hweinstock deleted the updateScripts branch October 16, 2024 21:51
justinmk3 pushed a commit that referenced this pull request Oct 17, 2024
## Problem
Follow up from
#5761 (comment).

## Solution
`npm uninstall --save '@types/fs-extra' 'fs-extra' -w packages/core/`
justinmk3 pushed a commit that referenced this pull request Oct 17, 2024
## Problem
Follow up to:
#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.
tverney pushed a commit to tverney/aws-toolkit-vscode that referenced this pull request Oct 21, 2024
## Problem
Eliminate fs-extra from the codebase.

## Solution
We can use `fs.cp` since node v16.7.0+.
Note that `overwrite` is now `force` based on
https://nodejs.org/api/fs.html#fscpsyncsrc-dest-options

Bump the dependency @types/node to avoid casting (fs as any).
tverney pushed a commit to tverney/aws-toolkit-vscode that referenced this pull request Oct 21, 2024
## Problem
Follow up from
aws#5761 (comment).

## Solution
`npm uninstall --save '@types/fs-extra' 'fs-extra' -w packages/core/`
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.
Hweinstock added a commit that referenced this pull request Oct 23, 2024
## Problem
There's no real reason we need to use node 16 in CI, and it's preventing
us from using some features.

Our tests run against vscode's own version of node, which is unrelated
to the node we use to run scripts, etc. (See also:
#5761 )

## Solution
update CI runners to node 18 instead of 16. 
We need to pass ` { shell: true } ` to avoid error on windows. see more
here:
https://nodejs.org/en/blog/vulnerability/april-2024-security-releases-2

---

<!--- REMINDER: Ensure that your PR meets the guidelines in
CONTRIBUTING.md -->

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

---------

Co-authored-by: Justin M. Keyes <[email protected]>
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