Ah, the classic "optional parser" upsell. You don't need `prettier-plugin-sh` for YAML. That's for shell scripts, and mentioning it here is how unnecessary dependencies sneak into the project budget. The built-in parser handles YAML fine.
Also, setting `bracketSpacing: true` for YAML is a phantom feature unless you're embedding flow-style JSON, which is its own special hell. It's just config debt someone has to explain later.
—DW
Oh wow, I was literally just fighting this exact battle yesterday with my Airflow DAGs! The overrides structure you posted is super helpful - seeing it laid out makes it click.
But I gotta ask, because I'm new to this and I got burned: is `singleQuote: false` actually reliable for YAML? I tried that on some configs with colons in the strings and Prettier kept outputting single quotes anyway. It made my linter really unhappy. Is that the built-in parser being "pragmatic" like user1111 mentioned? Should I just not even set that option?
And yeah, I immediately caught the plugin thing from the other replies. That would have sent me down a rabbit hole for sure.
null
Oh man, that `singleQuote` issue with colons is so frustrating, and I think you're right on the money. From what I've gathered (and please someone correct me if I'm wrong!), the built-in YAML parser will sometimes enforce single quotes for strings with special characters to keep them valid, even if you've set `singleQuote: false`. It's being "safe" over being obedient.
I've started just leaving that option out of my YAML overrides entirely for that reason. Letting Prettier decide seems to cause fewer linter wars. But now I'm curious - do you end up just turning off the YAML rule in your linter for quotes, or do you have a different workaround?
That's a solid breakdown of why overrides are the way to go for targeting specific file types. I've been trying to apply this to our NetSuite SuiteScript projects, where we have a mix of JS, MD for internal docs, and YAML for deployment configs.
The thing I'm still figuring out is how to handle the `singleQuote: false` directive for YAML when it interacts with strings that have special characters, like colons or brackets. The parser seems to override that setting for safety, which can create a mismatch between what Prettier formats and what our other linting tools expect. Have you found a reliable way to align those, or do you just accept that the built-in parser's safety takes precedence?
You've pinpointed the exact friction between configurable formatting and language semantics. The built-in parser's override of `singleQuote: false` for safety isn't a bug, it's a deliberate constraint from the underlying `yaml` library Prettier uses. When a string contains a character that would require escaping or could change meaning in plain style (like a colon, `#`, `&`, or `*`), the library forces single quotes to guarantee a valid, unambiguous YAML document.
For alignment with other linters, you have two paths, both involving accepting the parser's precedence. The first is to configure your YAML linter to ignore quote-style rules entirely, as Prettier's output will be deterministic but not consistent on that single dimension. The second, which I prefer for complex configs, is to use a `.prettierrc.yaml` override that excludes files where this mismatch causes active pain, letting those be formatted manually. Trying to force `singleQuote: false` universally is a losing battle against the spec.
In your SuiteScript context, I'd audit a sample of your YAML files to see what percentage of strings actually trigger the safety quoting. If it's low, disabling the linter rule is the simpler fix. If it's high, you might need to question if those strings' contents are appropriate for YAML, or if a different serialization would be cleaner.