A proposal for the .config/
directory.
The number of configs in projects is growing every day, and there is no convention to organize them!
The lack of a conventional place to organize configuration files led tools to often prefer to use top-level configuration files suffixed with .config
or rc
.
This makes things harder than they should be:
- For developers to quickly get started and understand a new codebase
- For repository maintainers, to manage config files
- For tools to distinguish config files
- For library authors to decide on where to store or load configs
This proposal aims to introduce a new conventional place for storing configuration files and motivate different tools to support it as a new alternative standard while allowing top-level conventions the same as before.
Note
More discussions related to this proposal, are moved under the Discussions section.
When the .config/
directory exists, tools read the config files inside this directory.
Usually, tools should use <dir>/.config/[name].[ext]
for file name convention.
As the size of the configuration increases, managing them all in a single configuration will be harder. Tools can optionally support .config/[name]/
to allow nesting.
In the case of monorepo when users need to specify multiple files of the same config, the config files can be nested into /<path>/.config
directory and based on the tool requirements either merged with mono repo's /.config
or not.
While this proposal does not enforce the naming convention of files inside this dir, it provides some recommendations and best practices.
Tool or framework names should be explicitly clear in configuration file names to avoid conflicting tools with each other and also make it clear for users what config is for what.
✅ .config/toolname.js
❌ .config/app.js
Since the .config
directory name is already clear it is holding configuration files, the .config
suffix is not needed and shall be avoided.
✅ .config/toolname.js
❌ .config/toolconf.js
❌ .config/toolname.config.js
Note
To make the migration to the .config
directory process easier and keep the existing file name conventions, tools might allow this suffix as an alternative.
Config files without clear extensions are harder to be parsed. Both by IDEs and other tools and also for end-users to understand.
✅ .config/toolname.toml
❌ .config/toolname
❌ .config/toolrc
Note
This proposal discourages using the rc
format because the syntax interpretation is ambiguous.
Using case-sensitive configuration file names can introduce cross-platform support issues. It is highly recommended to only use lowercase naming.
✅ .config/toolname.toml
❌ .config/toolName
Note
This proposal recommends using the kebab case if the tool name is too long tool-name.json
instead of a camel case like tool_name.json
to preserve consistency in this directory.
There are config/dot files that are common and unlikely to be nestable. These are excluded from the scope of this proposal:
.env
.gitignore
This is a big ecosystem issue and unless we push to unblock it, nothing will happen! The goal of this proposal is to make a centralized effort and discussion forum for tool authors to contribute.
- Make a tracker DB of tools with known configuration files and their status with this proposal
- Open individual issue trackers to each tool and invite them to collaborate
- Provide a preset configuration to use VSCode File Nesting with the
.config/
directory