Direction: what cfnrain keeps, cuts and builds after the first release

[allixsenos]

This thread is for one question: where does cfnrain go after it stops being a straight copy of rain? The fork announcement is in its own thread.

What is already decided

• Release 1 is the original rain code under the new name. Templates, !Rain::* directives, config files and artifact buckets work as they are.
• Release 2 is dependency updates and nothing else.
• Release 3 is the first release that may break compatibility. Every break needs a reason that a user would agree with.
• The goal is the best CloudFormation client, with maximum compatibility with native CloudFormation. New features need a real usability win. "Because we can" is not a reason.
• How we decide: if more people join, we steer together. If nobody does, I make the calls.

Open questions

Reply with the question number, so the threads stay readable.

1. What do you use? Tell us which commands and directives you rely on. This is the most useful answer you can give, even if you answer nothing else.

2. What do we cut? These are candidates, not decisions. Each one is experimental, stale or now done by CloudFormation itself:

   • cc (deploy through the Cloud Control API)
   • forecast (pre-deploy checks, some now done by CloudFormation's own validation)
   • module publish, install and bootstrap (modules in CodeArtifact)
   • build --prompt (template generation through Bedrock, defaulting to Claude 2)
   • Pkl input and output

3. Which new CloudFormation features come first? rain was archived before it could use them:

   • Express mode on deploy
   • a rollback error summary built on DescribeEvents
   • drift-aware change sets
   • force rollback for stuck rollbacks
   • a command around stack refactoring

4. Modules. Should cfnrain's Modules syntax stay compatible with the modules proposal in aws/aws-cli#9124? It would keep templates portable if AWS ever merges it.

5. Release 3 breaks. Candidates:

   • -x means --no-exec on deploy and --experimental everywhere else
   • buckets that rain created delete artifacts after 7 days, while the lifecycle rule says 14
   • the move off the archived gopkg.in/yaml.v3 library

   What else would you break, and what must never break?

6. Forecast plugins. Release binaries cannot load .so plugins. See issue Release binaries cannot load forecast plugins (CGO off) #13 before you answer.

7. Homebrew. It is planned, and it must ship before homebrew-core disables rain on 2027-02-08. See issue Publish to Homebrew before homebrew-core disables rain (2027-02-08) #14.

How to help beyond this thread

• Run your next deploy with cfnrain and open an issue for anything that behaves differently from rain v1.24.4.
• If you had an open PR or issue on the archived rain repository, link it here. We can port the good ones.

[allixsenos]

2. What do we cut? I removed each candidate in a scratch branch to measure the cost of keeping it. Nothing is merged, and these are still proposals. The numbers are below, so the discussion can use facts.

I also added one new candidate: all of build, not only build --prompt. The reason is in its row.

What each cut removes

Lines are non-test Go. "Gated" means that the feature works only with --experimental today.

Candidate	Gated	Lines	Tests	What goes with it
cc	yes	2,781	23% coverage	The Cloud Control API client
forecast	yes	3,761	58% coverage	6 AWS SDK clients (ACM, IAM, KMS, RDS, SageMaker, Service Quotas), the .so plugin interface (see #13)
module publish, install, bootstrap	yes	732	none	The CodeArtifact client
build (new candidate)	no	2,190	22% coverage	The Bedrock client, promptui, 1,589 embedded resource schemas (14 MB), and the release step that refreshes them
Pkl input and output	no	539, plus 596 in build --pkl-class	yes	apple/pkl-go and a dependency on the pkl CLI on your PATH

Together, these cuts change the project as follows:

• Go code goes from 35,500 lines to 22,100.
• The release binary goes from 41.8 MB to 23.1 MB.
• go.mod goes from 73 required modules to 43.
• All tests still pass after the cut. The commands that stay need no changes, except fmt and pkg, which lose their Pkl paths.

Notes on each candidate

cc, forecast and module are experimental, and you must opt in to each one. They hold most of the extra AWS SDK clients, and they have few tests or none. cc deploy calls forecast, so these two go together or not at all.

build is the hard one. It is stable, it is not gated, and cfnrain build AWS::S3::Bucket is a useful command. But it is the only reason to embed 14 MB of schemas. Each release must also refresh those schemas through DescribeType in a live AWS account. The CloudFormation Language Server now gives the same skeletons in an editor. There are three options:

1. Keep build as it is.
2. Keep build, but cut --prompt (Bedrock, default model claude2) and --recommend.
3. Cut build completely.

Pkl works only if you install the pkl CLI yourself. It never worked with diff, merge or tree. Its library is not at 1.0 yet, and it broke on the most recent dependency update. If you write templates in Pkl, run pkl eval -f yaml and give the YAML to cfnrain.

Cleanup that breaks nothing

The cleanup below removes no features, so it does not need to wait for release 3:

• internal/aws/lightsail. Its only caller is inside a commented-out block.
• cfn.GetTypeIdentifier. Nothing calls it.
• test/webapp. It is a sample app, and it is the only reason that go.mod has jwx, aws-lambda-go and the DynamoDB SDK.

What I need from you

• Do you use any of these features? Tell us which one, and what you use it for.
• For build, which option do you prefer: 1, 2 or 3?
• Is there a candidate that you think must stay? Give the reason.