fix: allow CloudFormation intrinsic functions for config fields (#638)#713
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: ⛔ Files ignored due to path filters (2)
📒 Files selected for processing (7)
🚧 Files skipped from review as they are similar to previous changes (4)
📝 WalkthroughWalkthroughWidened configuration types and extended JSON-schema validation to accept CloudFormation intrinsic functions for OIDC issuer, top-level xrayEnabled, and logging.excludeVerboseContent, and added tests confirming validateConfig accepts intrinsic-based values. ChangesCloudFormation Intrinsic Functions Support
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@src/types/common.ts`:
- Around line 102-103: The IntrinsicFunction union in
src/types/cloudFormation.ts is missing support for Fn::ImportValue, causing
fields typed as string | IntrinsicFunction (e.g., issuer and
excludeVerboseContent) to reject valid templates; add a new FnImportValue (or
ImportValue) interface/type representing { "Fn::ImportValue": string |
IntrinsicFunction } and include it in the IntrinsicFunction union (e.g., change
FnGetAtt | FnJoin | FnRef | FnSub to FnGetAtt | FnJoin | FnRef | FnSub |
FnImportValue), ensuring recursive nesting remains allowed so constructs like
Fn::Join containing Fn::ImportValue type-check correctly.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: defaults
Review profile: CHILL
Plan: Pro
Run ID: 5a242d1f-fc77-42e1-ad3d-0d7615c07919
⛔ Files ignored due to path filters (2)
src/__tests__/validation/__snapshots__/auth.test.ts.snapis excluded by!**/*.snapsrc/__tests__/validation/__snapshots__/base.test.ts.snapis excluded by!**/*.snap
📒 Files selected for processing (6)
src/__tests__/validation/auth.test.tssrc/__tests__/validation/base.test.tssrc/types/common.tssrc/types/index.tssrc/types/plugin.tssrc/validation.ts
1e4935c to
faa70a1
Compare
…udeVerboseContent (#638) Adds Fn::ImportValue to the IntrinsicFunction union so these fields type-check valid CloudFormation templates (incl. nested under Fn::Join), addressing the CodeRabbit review on src/types/cloudFormation.ts.
faa70a1 to
89c3173
Compare
Enable CloudFormation intrinsic functions for config fields
Fixes #638. Revives #640 (original work by @ronnyroeller).
Background
Before the v2 rewrite, several
appSyncconfig values could be set to CloudFormation intrinsic functions (Fn::Join,Fn::ImportValue,Ref, etc.). v2's stricter schema validation locked these fields to primitiveboolean/stringtypes, so configs like this stopped resolving:…failing with
at appSync/.../issuer: must be string.What this changes
Restores intrinsic-function support for the config values that are passed straight through to the generated CloudFormation template:
openIdConnectConfig.issuerxrayEnabledlogging.excludeVerboseContentImplementation:
booleanOrIntrinsicFunctionschema definition, mirroring the existingstringOrIntrinsicFunction.oneOfdefinition and widens the corresponding TypeScript types (boolean | IntrinsicFunction/string | IntrinsicFunction).must be a boolean/string or a CloudFormation intrinsic function.Intentionally not included
waf.enabled,logging.enabled,caching.enabled, anddomain.enabledremain plain booleans. These are synth-time toggles — the plugin checks=== falsein JS to decide whether to generate the resource at all, so a deploy-time intrinsic can't drive them. Accepting one would pass validation but silently always-create the resource, which would be worse than the current clear error.Tests
xrayEnabled,openIdConnectConfig.issuer, andlogging.excludeVerboseContent.xrayEnabled, a number forissuer, etc.).npm test(334),npm run test:e2e(84),npm run lint(0 errors),npm run build.Summary by CodeRabbit
New Features
Tests