fix: stop bundling aws-cdk-lib into Lambdas and avoid caching cdk.out

[Ignacio Nistal (ignacionistal)]

fix: stop bundling aws-cdk-lib into Lambdas and avoid caching cdk.out

Type of Change*

• New feature
• Bug fix
• Documentation update
• Refactoring
• Hotfix
• Security patch
• UI/UX improvement

Description

Lambda response helpers were accidentally pulling aws-cdk-lib into every handler bundle (~40–50MB each), which bloated synth/deploy disk use and slowed builds. This also stops Nx from caching cdk.out and cleans it up after successful local deploys so those assets stop accumulating on developer machines.

Testing*

Tested deployment on local machine and confirmed bundle size got much smaller.

Impact

This impacts local dev deployment.

Checklist*

• No new errors or warnings have been introduced.
• All tests pass successfully and new tests added as necessary.
• Documentation has been updated accordingly.
• Code adheres to the coding and style guidelines of the project.
• Code has been commented in particularly hard-to-understand areas.

[diegomayorga-dept]

Summary

• 2 blockers, 3 major, 3 minor
• Top concerns: pnpm run build-and-deploy is broken in both packages (pnpm forwards trailing CLI args by appending them to the end of the resolved script string; since deploy now ends in a compound if/fi, the flag lands after fi → shell syntax error — confirmed by reproduction). A second consecutive local back-end deploy can also fail because cdk.out is neither nx-cached nor present on disk anymore. Separately, the new hardcoded CORS-methods string duplicates an existing, differently-ordered copy elsewhere, and nothing tests the value.

Correctness (2)

blocker — packages/front-end/package.json

build-and-deploy now calls pnpm run deploy --require-approval any-change. deploy was changed to end in && if [ "${CI_CD:-}" != "true" ]; then rm -rf cdk.out; fi. pnpm/npm append trailing CLI args to the end of the resolved script string rather than routing them to a specific sub-command — reproduced directly with an equivalent script, getting sh: -c: line 0: syntax error near unexpected token. pnpm build-and-deploy in packages/front-end now fails before cdk bootstrap or deploy ever runs.

Suggestion: Don't forward CLI flags through pnpm run deploy <flag> into a script ending in if/fi. Read the approval mode from an env var inside deploy, or keep build-and-deploy as a fully inlined command instead of delegating to deploy.

blocker — packages/back-end/package.json

Same root cause. The modified deploy script now ends in the same if [...]; then rm -rf cdk.out; fi block. Back-end's existing build-and-deploy (untouched by this diff) already calls pnpm run deploy --require-approval any-change — previously harmless, it now breaks with the identical shell syntax error.

Suggestion: Same fix as front-end.

Conventions (1)

major — packages/shared-lib/src/app/utils/common.ts

The new ACCESS_CONTROL_ALLOW_METHODS hardcoded string duplicates an already-existing hardcoded copy of the same CORS method list in packages/back-end/src/infra/utils/openapi-spec-enrichment.ts (CORS_ALLOW_METHODS) — with a different method ordering (OPTIONS,GET,PUT,POST,DELETE,PATCH,HEAD vs GET,HEAD,OPTIONS,PUT,PATCH,POST,DELETE). This PR removes the one real source of truth (the CDK import) and adds a second, independently-maintained literal instead of pointing the existing one at it.

Suggestion: Have openapi-spec-enrichment.ts import ACCESS_CONTROL_ALLOW_METHODS from shared-lib's common.ts instead of keeping its own literal.

Tests (1)

major — packages/shared-lib/src/app/utils/common.ts

No test asserts the value of Access-Control-Allow-Methods for buildResponse/buildErrorResponse. The existing test only checks statusCode, body, and Access-Control-Allow-Origin. This is exactly the kind of change (CDK constant → hardcoded literal) that a future typo or aws-cdk-lib upgrade could silently drift on, and nothing would catch it.

Suggestion: Add an assertion on result.headers['Access-Control-Allow-Methods'] in both test cases.

Simplification (2)

minor — .projenrc.ts

The if [ "${CI_CD:-}" != "true" ]; then rm -rf cdk.out; fi fragment is duplicated verbatim in both the back-end and front-end deploy scripts, in the same file.

Suggestion: Extract it to a single const and interpolate into both scripts.

minor — packages/shared-lib/src/app/utils/common.ts

ACCESS_CONTROL_ALLOW_METHODS is a pre-joined string while its sibling ACCESS_CONTROL_ALLOW_HEADERS (same file, same role, defined right below it) is an array joined at each call site — inconsistent shape for two constants doing the same job.

Suggestion: Declare it as an array and .join(',') at the call sites, matching ACCESS_CONTROL_ALLOW_HEADERS.

Breaking Changes (1)

major — projenrc/nx.ts / nx.json

build's nx outputs no longer include cdk.out (now just lib). Root build-back-end/build-and-deploy invoke pnpm nx run-many --targets=build ... for back-end with no NX_SKIP_NX_CACHE/nx reset. On a cache hit (no back-end/shared-lib source changes since the last build), nx skips re-synthesizing and no longer restores cdk.out from cache either. Combined with this PR's own rm -rf cdk.out after a successful local deploy, a second consecutive local build-and-deploy with no code changes will find cdk.out missing and fail at pnpm cdk bootstrap --app cdk.out. Front-end is incidentally unaffected because build-front-end runs nx reset && unconditionally; CI is unaffected because cicd-build-deploy-* scripts set NX_SKIP_NX_CACHE=true. This is back-end-local-only.

Suggestion: Force a fresh synth before every local back-end deploy (mirror front-end's nx reset && in build-back-end), or keep cdk.out nx-cacheable and make the cleanup a separate step that doesn't fight the cache.

PR Hygiene (1)

minor — PR

Title and body have no ticket reference, breaking the repo's ticket-prefix title convention (e.g. EGV-175 ...).

---

Security: no findings.

[Kevin Loftus (kevin-loftus-dept)]

Bug: cached builds can no longer produce a deployable cdk.out

This refactor removes cdk.out from Nx build.outputs, but deploy still consumes cdk.out (cdk bootstrap --app cdk.out / projen deploy --app cdk.out). Since deploy depends on a cacheable build, a cache hit will now restore lib/ but not the cloud assembly, so the next deploy can fail with a missing cdk.out even though Nx says build is up to date. The new rm -rf cdk.out on local deploy makes that path even easier to hit.

Also, build-and-deploy now calls pnpm run deploy --require-approval any-change, but the deploy script doesn’t forward that arg into the inner projen deploy command, so the approval flag is no longer being explicitly applied.