Next.js, etc. the JS ecosystem has come a long way, especially for newer developers who just want to start working on an app and don't want to spend hours learning how to setup multi-hundred-line config files.
I don't think that this means configuration shouldn't exist at all. As much as possible, a tool should try to have sensible defaults that covers the general use cases. The user should be allowed to customize further on top of that if they wish, but ideally there should be a working product out of the box. Also, there should be an attempt to keep these config options as simple as possible – when designing your config schema, try to prefer boolean values for most things (if possible) for turning settings on/off rather than using strings to specify what the user wants to allow/reject.
One tool in particular that does this well is
Prettier, a code formatter. There are very few configuration options for it, with most of them being simple boolean values (like
semi: false), and most of the defaults follow the conventions set by the JS community. This will be even more true once v2 is released which is improving some default settings like using single quotes instead of double.
I was inspired to write this post after some learning some lessons from releasing a tool called
In retrospect, this was a mistake. No feature (like lint rule customization) should be removed from a tool, unless there is some benefit gained in return. Removing style rules from the linter made sense because it encouraged the use of a code formatting tool like Prettier (which is more suitable for enforcing code style when compared to a linter). However, there was no benefit from removing the customization of other rules like
prefer-const, etc. I've realized my mistake, and the next version of
lynt will let the user have extra configuration for non-style rules.
Configuration is not a bad thing, when done properly. When designing a tool, remember to make it have sensible defaults and to limit/simplify config options.