Any time I see a nodejs tool aimed at systems tasks (general infrastructure, IaC, etc) I immediately disregard it. While, to be honest, I'm not sure that's a fair way to look at tools like this, it's the reality.

I always wonder at the authors motivation to use node when the majority of the ecosystem is written in golang. This is actually one of the main reasons I dont use terraform CDK right now. Why is CDK node first (I know there is golang support) when terraform is all golang?

I agree that it's weird to write any command-line tool in Node. Very few developers have `npm` installed.

This looks really cool! I wonder if it only checks for collisions in the current statefile/template, or whether it actually makes call to the cloud provider and checks for even external collisions there? Though I guess that would be very complicated to accomplish without writing tons of glue code.

That said, if you like infra-as-code and are scaling your usage to more people, I recommend taking a look at tools like Spacelift[0].

We're a CI/CD that's specialized for infra-as-code and integrate very deeply with Terraform, CloudFormation, and similar tools workflows. This way we can give you better visibility, security and easy customizability through automations that are tailor-made for infra-as-code use cases. You can ofc additionally also hook in tools like this one.

Esp. if you want a single team creating reusable templates and guardrails for the whole company, Spacelift can help you a lot, but it's very useful for any bigger group of people using IaC together.

Disclaimer: Software Engineer at Spacelift, grains of salt shall be taken with the above

[0]: https://spacelift.io

Hey Cube! It does indeed run checks against the cloud as well for things like naming collisions and quota allocation

Could you expand on how you're doing that, technically? I'm really curious and can't find it in the code, skimming it quickly.

Yeah, so this package itself is the core framework that establishes how these tests are to be run. There is a notion of plug-ins, which are parsers and checks. Parsers take cdk or terraform code and break their synthesized/planned output out into a common structure. Then checks run over that structure and pull data in from elsewhere and run actual validations. You can read more in the developing plugins doc on the repo https://github.com/tinystacks/precloud/blob/main/DEVELOPING_....

The default plugins present are the 6 mentioned here https://github.com/tinystacks/precloud/blob/main/PLUGINS.md. They’re all published on npm and github

Oh, that's cool, thanks for the explanation!

Suggestion: Please add a license and fill out the About section in the GitHub repo.

Done!

It looks like an useful tool, thank you! It looks like it's written in JS and has several dependencies so for security reasons I'd run it on a separate box to minimize blast radius.

Good idea. I recommend running it in your ci cd provider as a post-build stage (I.e. reference it in your github/gitlab workflow on each pull request)

Some similar IaC dynamic analysis tools written in golang:

https://github.com/terraform-linters/tflint-ruleset-aws/blob...

https://github.com/aws-cloudformation/rain/pull/93

This is really cool. I am co-founder of Terrateam[0] and we see failed runs for these reasons a lot more than we expected and it's dangerous. It wastes time and a failure during an apply leaves your infrastructure in an inconsistent state. I'm excited to play with this.

[0] https://terrateam.io

I see that GCP support is "coming soon"--even just a quota comparison would be really nice, as these are numerous and a big pain there. Any ETA on when there might be something for GCP?

We don't have an ETA there yet. I opened issues for GCP support, please +1 them to help us prioritize! https://github.com/tinystacks/precloud/issues

Can it check for the cross stack reference issues (export removed from a provider stack, but still used in the consumer stack).

It can be made to! It needs a plugin for that, the default plugins don't support that.