A contract is the part of an interface that other people or programs rely on. In Terraform work, a module’s variable names, a command’s JSON output, and a provider’s available resources can all become contracts. Once others depend on them, even a small change can affect their work. section 9.6 section 11.1.1 section 12.1
A small name, a recurring cost
Suppose two modules both accept subnet IDs, but one calls its input `subnets` and the other calls it `subnet_ids`. Both may work, yet users must keep checking which name each module expects. Standardizing an interface can improve usability; changing an existing name also requires care because users may already depend on it. section 9.6
Identify the contract before building on it:
- For a module, decide which inputs users will supply and keep their names consistent across related modules. section 9.6
- For a command wrapper, use `-json` rather than parsing human-readable output. Single-response commands such as `show` return one JSON object; commands such as `plan` stream independently parseable JSONL records. section 11.1 section 11.1.1
- For a provider, decide which resources, data sources, and functions users should have before writing code. A backward-incompatible provider change may affect many modules. section 12.1
Listing 12.1 Mastodon provider examples
terraform {
required_providers {
mastodon = {
source = "terraformindepth/mastodon"
}
}
}
provider "mastodon" { #1
host = "https://hachyderm.io"
}
data "mastodon_account" "me" { #2
username = "tedivm"
}
resource "mastodon_post" "this" { #3
content = "Hello, World!"
}
The provider example shows the intended user-facing surface: host configuration, an account lookup, and a post resource. Designing those uses first makes the interface easier to assess before implementation. section 12.1
Treat machine-readable formats as documented contracts, not as incidental display text. A wrapper must run commands, handle errors, parse their results, and check current field documentation for changes. Likewise, settle provider interfaces with compatibility in mind before other modules begin relying on them. section 11.1 section 11.1.1 section 12.1
