Conform.nvim: Troubleshooting `inherit = False` Formatter Configuration
Hey there, fellow Neovim users! Ever run into those head-scratching moments when a configuration setting seems to break everything? If you've been tinkering with conform.nvim, you might have encountered a peculiar issue when trying to set inherit = false within your formatter configurations. It’s a common scenario: you want to customize a specific formatter, maybe to override its default behavior or apply a unique set of rules, and you stumble upon this inherit option. Your first thought might be, "Great! This must be how I tell conform.nvim to only use my settings and ignore any inherited ones." But, as you've probably discovered, things can get a bit tricky, and suddenly, :ConformInfo starts showing errors, and your formatters just won't load. This article is here to demystify that inherit = false setting and guide you through what's really going on under the hood, ensuring your formatters work smoothly.
Understanding the inherit Option in conform.nvim
The core of the issue often lies in how conform.nvim handles configuration merging. When you define formatters in your conform.nvim setup, you have the ability to specify custom settings for each one. The inherit option, as you correctly observed, plays a crucial role in this process. Its intended purpose is to control whether conform.nvim should merge your custom formatter configuration with the default configuration provided by the plugin. Setting inherit = true (which is often the default behavior if not explicitly set) means conform.nvim will take the default settings and then layer your custom settings on top, overriding any conflicts. This is incredibly useful when you only want to tweak one or two options for a formatter while keeping the rest of the sensible defaults intact.
However, when you set inherit = false, you're essentially telling conform.nvim, "Forget all the defaults; I want to provide the complete configuration for this formatter myself." The problem, as you pointed out, is that if you only set inherit = false and don't provide any other configuration options for that formatter, conform.nvim might end up with an empty or incomplete configuration for that specific tool. This can lead to the formatter not being loaded correctly, or even causing conform.nvim itself to fail during its initialization or when trying to apply formatting. Your suspicion about M.get_formatter_config is quite astute. If the function expects a configuration table and receives nil or an improperly structured table because inherit = false wasn't handled with a fallback or an explicit configuration, it can indeed lead to the observed failures. It’s a classic case of a variable intended for control causing unexpected behavior when its implications aren't fully met by the surrounding code logic.
The inherit = false Dilemma and Expected Behavior
So, is setting inherit = false the right way to customize a formatter, or is the current behavior expected? To answer that, let's dive a little deeper into the why. When conform.nvim is processing your configuration, it looks at each formatter you've defined. If inherit is not explicitly set or is set to true, it fetches the default configuration for that formatter (e.g., the command to run, its arguments, etc.) and then applies your custom overrides. This is the standard, robust way to make minor adjustments. But when inherit = false, conform.nvim essentially throws away the default configuration. The expectation here is that you, the user, are providing the entire configuration object for that formatter. If you only provide inherit = false and nothing else, you're essentially telling conform.nvim to use no configuration for that formatter, which is why it fails to load. It's not that inherit = false is inherently broken; rather, it's a directive that demands a complete, self-contained configuration from you.
Think of it like this: inherit = true is like saying, "Start with this blueprint, and I'll tell you which rooms to paint a different color." inherit = false is like saying, "Here's a completely new set of blueprints; use only these." If you hand over an empty piece of paper when you're supposed to provide new blueprints, the construction (in this case, formatter loading) can't proceed. Therefore, the behavior you're observing is likely expected given the way inherit = false is designed to function: it signals a complete takeover of the configuration, not just a modification. To make inherit = false work, you need to provide the full details of the formatter's command, arguments, and any other relevant settings that would normally be inherited.
Practical Solutions and How to Correctly Configure Formatters
Now that we understand the underlying mechanism, let's talk solutions. If you truly intend to override all default settings for a formatter, setting inherit = false is indeed the correct directive. However, as we've established, you must then provide the complete configuration yourself. This means explicitly defining the command, args, and any other necessary parameters that conform.nvim needs to execute the formatter. For instance, if you want to completely redefine how prettier is run, you wouldn't just do this:
formatters = {
prettier = {
inherit = false,
}
}
Instead, you would need to provide the full command and arguments, like so:
formatters = {
prettier = {
inherit = false,
command = "prettier",
args = {"--write", "--config-yaml", "my_custom_prettier_config.yaml"},
*}
}
In this example, we're not only telling conform.nvim not to inherit defaults but also specifying exactly which command to run (prettier) and what arguments to pass to it. This gives conform.nvim all the information it needs to successfully invoke the formatter.
On the flip side, if your goal is simply to modify one or two settings of an existing formatter while keeping the rest of the defaults, then you should not use inherit = false. Instead, you can either omit the inherit key altogether (as true is often the default) or explicitly set inherit = true. Then, you only need to specify the settings you wish to change. For example, if you just want to add an extra argument to eslint_d without changing its core behavior:
formatters = {
eslint_d = {
-- inherit = true, -- This is often implied or default
args = {"--fix-imports", "--trailing-comma", "all"},
}
}
In this case, conform.nvim will fetch the default eslint_d configuration and then merge your provided args into it. This approach is generally simpler and less error-prone if you're just making minor adjustments. Always check the conform.nvim documentation for the specific formatters you are using to understand their default configurations and available options. Tools like :ConformInfo are invaluable for debugging and understanding the effective configuration being applied.
Conclusion: Navigating conform.nvim Formatter Settings
To wrap things up, the inherit = false setting in conform.nvim is a powerful tool, but it comes with a clear responsibility. It's not a bug when it causes a formatter to fail if left with an incomplete configuration; rather, it's a directive signaling that you're taking full control. The key takeaway is to understand what you want to achieve. If you want to completely redefine a formatter's behavior from the ground up, use inherit = false and provide all the necessary configuration details, such as the command and its arguments. If, however, you just want to tweak a few default settings, it's often better to rely on the default inheritance (inherit = true or omitting the key) and only specify the parameters you wish to override. By understanding this distinction, you can confidently configure your formatters in conform.nvim, avoid common pitfalls, and ensure your code is always formatted just the way you like it. Remember to always consult the plugin's documentation and use diagnostic tools like :ConformInfo when troubleshooting. Happy coding!
For more in-depth Neovim configuration tips and best practices, check out the official Neovim documentation.
