Modules

[ericzbeard]

I would like to gather feedback from the community on the new design for Rain Modules. The prior way to enable multi-file support was to use the Rain::Module directive in a resource type. That way still works, for the purposes of backwards compatibility, but the most recent release of Rain adds new and improved functionality that puts modules into a new section called Modules. The docs for modules are in the main README here.

In addition to modules, we now have support for Constants and a few useful intrinsic functions that are only available via the pkg command. Rain modules basically give you the power of Terraform modules or CDK constructs, but for declarative CloudFormation YAML.

The goal with these changes is to keep Rain compatible with the module functionality we are building into the AWS CLI, and to give users a chance to try out modules before we actually release changes to the aws cloudformation package command. We don't have an "experimental" flag for the official CLI, so once we release it, the design is basically set in stone.

One of the big questions we have is: If we release this without an official AWS module library (like the CDK L2 library, or like what's available for Terraform), will this have a big affect on adoption? Is it necessary? Or can everyone write their own modules for common use cases?

Tagging a few of our enthusiastic users and contributors here. Thanks for your support!

@t-jones
@iainelder
@lesterjude
@b0tting
@jsutton
@null93
@ugwis
@a-mymt
@bartleboeuf
@edgdelgado
@filipeandre
@dhutchison
@JWFGit
@paul-e-allen
@mrinaudo-aws
@andrius-paurys
@hariprakash-j
@jameslevine
@TheDanBlanco
@gouglhupf
@skrisyuk
@tam0ri
@khmoryz
@leinardi
@haytok
@georgealton

[iainelder]

Thanks for the news! This looks big. I need time to read it in detail, but I'm really excited to see these some of these ideas making it into the core CLI.

I don't think adoption needs a official module library. Instead it needs to be easy for any developer to publish and share modules.

pre-commit, the Git pre-commit hook manager, is an example to follow.

pre-commit has no official module library, and yet thousands of projects use it to check their code, using hundreds of community-maintained hooks.

pre-commit works without an official library because it's easy to publish new hooks and it's easy to use them in another project. To publish, you create a GitHub repo and add a .pre-commit-hook.yaml file. To consume, you include the repo URL and a tag in another repo's .pre-commit-config.yaml.