[hamandcheese]

What really grinds my gears is how hard it is to refactor terraform code. Put something in a module, but want to move it elsewhere? Get ready for pain.

I've been using terranix, which uses nix to generate a tf.json file, and oh my god is the experience night and day. I can make functions! I can refactor! And if it's a pure refactor, there is nothing to apply.

[cdchn]

How does terranix help you with the "move a resource from a module to somewhere else" problem?

[hamandcheese]

It helps because you don't use terraform modules at all, any abstraction you need can be done in nix before tf.json gets written.

[JohnMakin]

I know many people find it painful but isn't this fairly simple with "terraform state mv?"

my process is roughly:

comment out the resource in the module, run a plan -> get output like:

"module.foo1.aws_resource.bar will be deleted"

Then copy my resource in source to module.foo2.aws_resource.bar, the command becomes:

terraform state mv module.foo1.aws_resource.bar module.foo2.aws_resource.bar

I guess this might be harder if you're using upstream "official" modules, but I avoid those like the plague.

[rjbwork]

You don't even need to do state mv anymore. They added the `moved` block a while ago. You can then delete it from the source after your apply at your leisure.

[hamandcheese]

"Every change requires two PRs that aren't in the same terraform run" still way way way too much mental overhead just to do a simple refactor.

[hamandcheese]

Yea, there are tools to work around it, but the fact that a pure refactor would impact terraform state at all is the design flaw in my eyes.

Suddenly, just to refactor the source in a way that shouldn't touch any resources, you have to have be able to mutate the terraform state. (Or use the more recently introduced moved blocks, which is still quite a big kludge).

This means any kind of broadly sweeping refactor (which might impact many different state files) is really hard.