feat: improve performance in storing current cloud backend

[ErlendHer]

Description of changes

This PR addresses the issue where for large repositories with JavaScript resources, the "saving deployment state" step can be incredibly slow. For large repositories, more than 20 minutes. The cause of this performance issue is unoptimised code copying over all node_modules to the #current_cloud_backend directory, then using a glob and deleting any node_modules that were copied. This is extremely inefficient, and the proposed changes simply ignores and do not copy over node_modules in the first place.

Benchmark
benchmark of the time it takes to process 1 randomly selected TypeScript lambda function from our repository
Before: 15.410s
After: 0.009s (9ms)

This is a reduction from 15 seconds down to 9 milliseconds. For our repository, this would reduce the copying step of "saving deployment state" from 20 minutes down to roughly a second.

Issue #13814

13814

Description of how you validated changes

Tried running a deploy with amplify-dev before and after the changes and verifying that the output of #current_cloud_backend are identical

Checklist

• PR description included
• yarn test passes
• Tests are changed or added
• Relevant documentation is changed or added (and PR referenced)
• Pull request labels are added

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[0618]

Thank you for contributing @ErlendHer ! Could you please remove the const removeNodeModulesDir... so that the PR testing check can pass on this file?

warning 'removeNodeModulesDir' is assigned a value but never used @typescript-eslint/no-unused-vars

[ErlendHer]

Thank you for contributing @ErlendHer ! Could you please remove the const removeNodeModulesDir... so that the PR testing check can pass on this file?

warning 'removeNodeModulesDir' is assigned a value but never used @typescript-eslint/no-unused-vars

Sorry for late response, have been out on holiday. Yes of course. It's been removed now

[awsluja]

This is great, the PR checks are failing because the commit history is showing 'feat:', which involves making other version bumps to packages. Since this is purely a performance improvement, we can do this as a patch.

To do so, you can commit this as a 'fix' commit. That way, it results in a patch bump.

Ie, re-open this PR from a new branch, where you've committed this change as a 'fix' commit instead of a 'feat' commit.

[ErlendHer]

This is great, the PR checks are failing because the commit history is showing 'feat:', which involves making other version bumps to packages. Since this is purely a performance improvement, we can do this as a patch.

To do so, you can commit this as a 'fix' commit. That way, it results in a patch bump.

Ie, re-open this PR from a new branch, where you've committed this change as a 'fix' commit instead of a 'feat' commit.

I rewrote history and changed the commit message instead, does that now work?

[stevenlemon-sh]

Any chance we could get an indication of why the AWS CodeBuild pipeline failed? Details from the failure aren't publicly accessible.

Would love to see this PR get merged, as I am having similar performance issues to ErlendHer.