Hey everyone! I'm just starting with Copilot and found its Terraform suggestions a bit... wild. It kept mixing `snake_case` and `camelCase` for resource names, and the formatting was inconsistent. I wanted it to match my team's style guide, so I dug into how to guide it better.
I found you can add a `.editorconfig` file to your repo. Copilot reads it! Here's what I added for Terraform:
```editorconfig
root = true
[*]
indent_style = space
indent_size = 2
end_of_line = lf
charset = utf-8
trim_trailing_whitespace = true
insert_final_newline = true
[*.tf]
indent_size = 2
```
I also made a `terraform.tfvars.example` with examples of our naming patterns, like `app_name = "my_app"` and `env = "stg"`. Seems like Copilot uses nearby files as context. After adding these, the suggestions got way more consistent. Anyone else tried something similar for AWS configs or other languages?
That's a really useful approach, and your observation about Copilot using nearby files for context is spot on. I've found that for AWS CloudFormation or CDK, including a commented-out example resource with your preferred naming convention in the same directory can have a similar steering effect.
A small caveat is that the effectiveness of .editorconfig seems to depend heavily on the language server and editor integration. For some team members using different IDE setups, we've had to pair it with a linter configuration file to get fully consistent results across the board. Have you noticed any differences in how suggestions appear between, say, VS Code and Neovim?
Let's keep it constructive
Interesting point about the linter config! I'm only using VS Code, so I hadn't considered how it might differ in another editor. That's a bit worrying for team consistency.
Your trick with the commented-out example is clever. I wonder if that works for other stuff, like database schemas? Might have to try that for my own projects.
Has pairing the linter file with the .editorconfig been pretty reliable for your team across different setups?
The "different editor" worry is real, but maybe we're putting the cart before the horse. Your team's real problem isn't Copilot's inconsistency - it's that you're relying on an autocomplete tool as your source of truth for style in the first place.
That commented example trick is just a form of hoping the AI picks up the right pattern. It works until it doesn't, and then you're debugging why Copilot suggested `customer_id` in one file and `customerId` in another. Pairing a linter config helps, but only if everyone's editor is actually running the linter on the suggested code before they blindly accept it. How many people do you think have that set up?
For database schemas? Sure, it might work. But now you're maintaining a shadow style guide in commented code snippets instead of a single, enforced standard. That sounds like more work, not less.