I'm an AWS newbie so may be missing something simple. I followed the instructions for this and keep coming across errors. Am I right in thinking that the application is no longer being updated? Being new to AWS shell and bash, I used Ai to help try and resolve the issues to no avail, this is it's roundup of what I came across.
Any help gratefully received.
Environment Details
- Deployment Environment: AWS CloudShell (Region: eu-west-2)
- Default OS Image: Amazon Linux 2023 / Node.js v20.20.2 / npm v10.x
- Target Configurations Selected: Default CloudFront Domain, SAML (Microsoft Entra ID) Identity Provider
Description of Problems Encountered
1. Fatal Missing AWS SDK Dependency in Wizard
When running the interactive script via ./install.sh or npm run wizard, the Node/TypeScript engine instantly crashes before prompting for parameters. The utility references the AWS SDK v3 STS client but fails to declare or bundle it.
-
Terminal Error:
TSError: ⨯ Unable to compile TypeScript:
src/util/getAccountDetails.ts:1:53 - error TS2307: Cannot find module '@aws-sdk/client-sts' or its corresponding type declarations.
1 import { STSClient, GetCallerIdentityCommand } from "@aws-sdk/client-sts";
-
Impact: Completely blocks out-of-the-box script usage. Users must manually force-install @aws-sdk/client-sts inside the util/installer/ directory to pass this phase.
2. Hard Drive Storage Exhaustion (ENOSPC) in AWS CloudShell
AWS CloudShell instances have a hard storage ceiling of 1 GB in the user's home directory. The script installation method generates deep nested dependency trees (node_modules) across multiple workspaces (/infrastructure and /util/installer), causing the environment to run completely out of storage space.
-
Terminal Error:
npm error code ENOSPC
npm error syscall write
npm error nospc ENOSPC: no space left on device, write
-
Impact: Corrupts local package cache allocations and prevents completion of the manual or automated deployment workflows.
-
Suggested Fix: Transition the installer dependencies to an in-memory streaming execution framework, optimize package sizes, or advise users against deploying from standard CloudShell instances.
3. Cloud Assembly Schema Version Mismatch
The local application dependencies specify a modern cloud assembly specification schema version (50.0.0). However, the embedded deployment client wrapper relies on an outdated alpha wrapper library (@aws-cdk/cli-lib-alpha) that drops back to older schema restrictions (43.x.x or 48.x.x), triggering a critical compatibility halt.
-
Terminal Error:
_ToolkitError: This CDK CLI is not compatible with the CDK library used by your application. Please upgrade the CLI to the latest version.
(Cloud assembly schema version mismatch: Maximum schema version supported is 43.x.x, but found 50.0.0. You need at least CLI version 2.1105.0 to read this manifest.)
-
Impact: Blocks live infrastructure compilation even if dependencies are manually refreshed.
4. TypeScript Declaration Blocks via --omit=dev Optimization
When attempting to optimize disk space to bypass the ENOSPC limits by utilizing production flags like --omit=dev during dependency installations, the internal TypeScript checker throws runtime compilation blocks due to missing Node environment bindings (e.g., @types/node).
- Terminal Error:
bin/doctran.ts:25:2 - error TS2591: Cannot find name 'process'. Do you need to install type definitions for node? Try npm i --save-dev @types/node
bin/doctran.ts:32:2 - error TS2584: Cannot find name 'console'.
5. Lack of Standalone Native CloudFormation Templates (pipeline.yaml)
The local installation utility relies entirely on local environment setups instead of providing a standalone S3-hosted template deployment strategy. Because the pipeline.yaml is not hosted in an active AWS S3 endpoint bundle, launching a headless deployment via aws cloudformation create-stack --template-url fails.
I'm an AWS newbie so may be missing something simple. I followed the instructions for this and keep coming across errors. Am I right in thinking that the application is no longer being updated? Being new to AWS shell and bash, I used Ai to help try and resolve the issues to no avail, this is it's roundup of what I came across.
Any help gratefully received.
Environment Details
Description of Problems Encountered
1. Fatal Missing AWS SDK Dependency in Wizard
When running the interactive script via ./install.sh or npm run wizard, the Node/TypeScript engine instantly crashes before prompting for parameters. The utility references the AWS SDK v3 STS client but fails to declare or bundle it.
Terminal Error:
TSError: ⨯ Unable to compile TypeScript:
src/util/getAccountDetails.ts:1:53 - error TS2307: Cannot find module '@aws-sdk/client-sts' or its corresponding type declarations.
1 import { STSClient, GetCallerIdentityCommand } from "@aws-sdk/client-sts";
Impact: Completely blocks out-of-the-box script usage. Users must manually force-install @aws-sdk/client-sts inside the util/installer/ directory to pass this phase.
2. Hard Drive Storage Exhaustion (ENOSPC) in AWS CloudShell
AWS CloudShell instances have a hard storage ceiling of 1 GB in the user's home directory. The script installation method generates deep nested dependency trees (node_modules) across multiple workspaces (/infrastructure and /util/installer), causing the environment to run completely out of storage space.
Terminal Error:
npm error code ENOSPC
npm error syscall write
npm error nospc ENOSPC: no space left on device, write
Impact: Corrupts local package cache allocations and prevents completion of the manual or automated deployment workflows.
Suggested Fix: Transition the installer dependencies to an in-memory streaming execution framework, optimize package sizes, or advise users against deploying from standard CloudShell instances.
3. Cloud Assembly Schema Version Mismatch
The local application dependencies specify a modern cloud assembly specification schema version (50.0.0). However, the embedded deployment client wrapper relies on an outdated alpha wrapper library (@aws-cdk/cli-lib-alpha) that drops back to older schema restrictions (43.x.x or 48.x.x), triggering a critical compatibility halt.
Terminal Error:
_ToolkitError: This CDK CLI is not compatible with the CDK library used by your application. Please upgrade the CLI to the latest version.
(Cloud assembly schema version mismatch: Maximum schema version supported is 43.x.x, but found 50.0.0. You need at least CLI version 2.1105.0 to read this manifest.)
Impact: Blocks live infrastructure compilation even if dependencies are manually refreshed.
4. TypeScript Declaration Blocks via --omit=dev Optimization
When attempting to optimize disk space to bypass the ENOSPC limits by utilizing production flags like --omit=dev during dependency installations, the internal TypeScript checker throws runtime compilation blocks due to missing Node environment bindings (e.g., @types/node).
bin/doctran.ts:25:2 - error TS2591: Cannot find name 'process'. Do you need to install type definitions for node? Try
npm i --save-dev @types/nodebin/doctran.ts:32:2 - error TS2584: Cannot find name 'console'.
5. Lack of Standalone Native CloudFormation Templates (pipeline.yaml)
The local installation utility relies entirely on local environment setups instead of providing a standalone S3-hosted template deployment strategy. Because the pipeline.yaml is not hosted in an active AWS S3 endpoint bundle, launching a headless deployment via aws cloudformation create-stack --template-url fails.