the creeping scourge of tooling config files in project root directories

[boneskull]

Splitting this out from #71 which was rather broad. There are (at least) two separate issues there; one is where user-specific config files should live, and another is where project-specific config files should live. This issue is about project-specific config files.

The files we're talking about are configuration files for development dependencies and are committed to VCS.

Many projects suffer from the problem of too many config files in the project root, as @iansu tweeted:

We put config files in the project root because we put config files in the project root. There is no reason other than a lack of an alternative convention.

We can do better than this. The idea is we aim for a "critical mass" of popular tooling authors moving their project-specific configuration to a subdirectory (e.g., .config/). If we can agree on a subdirectory, and change our tools to support the new subdirectory, we will significantly reduce this problem. It's our hope (though not a strict requirement) that the convention we agree upon will be flexible enough to reach beyond the JS ecosystem. For instance, your .travis.yml and netlify.toml could live in this directory as well, if this idea becomes popular enough.

We should get buy-in from maintainers of popular tools; if these tools adopt the new subdirectory, it's likely the ecosystem will slowly follow suit.

cc @nodejs/tooling @nodejs/package-maintenance

[styfle]

Would this new subdirectory also include package.json config?

[boneskull]

@styfle Whether any given tool uses the subdirectory is up to the maintainers of that tool. For npm in particular, this seems like perhaps a risky move, given there are many assumptions across userland tools about where package.json lives.

[boneskull]

(It's not really npm's to move, either... they aren't the only consumers of it, obv)

[coreyfarrell]

Moving package.json to a subdirectory would also be problematic for Node.js where the package.json "type" field is set.

[ljharb]

Moving eslint config would be problematic for the same reason, since it composes up the hierarchy, and describes the current folder.

[bcoe]

what if a folder such as .config/ had identical semantics to if the file existed in the root? e.g., test/.eslintconfg.json still took precedence.

[ljharb]

Then how would I lint my JS config files inside .config?

[boneskull]

I don’t think that’s an unsolvable problem.

[ljharb]

It’s a problem that doesn’t need to exist tho. I think it might make sense to come up with a conventional location for some kinds of config files - project-level ones, mainly - but not for directory-level ones, like eslint/babel/npmrc/gitattributes perhaps/etc.

[jedwards1211]

@ljharb well .config/.eslintrc would apply to JS files inside .config since it applies to the parent folder. There would only be an issue if you JS files in .config and parent folder to be linted differently.

@boneskull on the other hand, IDEs could be made to show dotfiles in a pseudo-directory.

I agree that this becomes a bit disorienting, especially when I have a bunch of project folders open in my workspace and I'm scrolling between them.

[ljharb]

Yes, i would assume my config file would match the node version eslint runs in, but my actual files would match the node versions my production code targets - iow i think that’s the most common case.

[ahmadnassri]

this issue mentions "user-specific" and "project-specific" config files, I would argue, while those are important and the noise ratio is quite high per project, however a more important vector to consider is "org-specific" config files.

regardless of team size, small and large teams might be in a situation where they have to manage hundreds of projects (up to thousands in case of enterprises), those projects might be independent repositories or a collection of mono-repos with many packages and/components within.

a potentially more inclusive approach to consider here, is having a central external spot for all config files, that apply by default to each project / repo, and any local file is considered inheritance / override, thus the Patten becomes:

• no local configs => use org-wide defaults
• some local configs => use org-wide defaults and override specific declarations

this would massively shrink the configuration footprint, for both individuals and teams.

some challenges with this approach:

• how do you make clear to a visitor that this projects is pulling it's config files from somewhere else?
• would local files "override" or "extend" the source

some good relevant references here (though still rely on a local file)

• eslint shareable configs
• semantic-release shareable config
• probot "extends"

[ljharb]

a config tho that lives outside the repo won’t be easily shareable across multiple devs.

[ahmadnassri]

a config tho that lives outside the repo won’t be easily shareable across multiple devs.

I would argue eslint, semantic-release, renovate bot and others have done a good, positive job of setting a pattern here (they use packages) that make it easily shareable