I'm delayed, but I suggest _configs/ (or _config/ if singular is preferable)

Reasons:

1. Files with a dot prefix in the name: They are treated as hidden files on Linux (and maybe Mac)

.config/ and other directory names starting with a dot are treated as hidden directories on Linux and other Unix(-like) systems (maybe including Mac?), as mentioned in the suggestion for config.

This is one of the reasons why the Vite team didn't accept this .config/ proposal.

vitejs/vite#15911 (comment)

.config/, .conf/, and .meta/ have this problem.
However, _conf/, and _meta/ work as the alternatives.

2. config/ conflicts with some frameworks (especially PHP's)

config/ does not work in some cases because some frameworks use config/ as its configuration directory and the directory name is overlapped.
I have never seen such frameworks using the config/ directory in JS ecosystems, but some PHP frameworks use it. The following PHP frameworks use config/ as their configuration directory.

• Laravel
• Symfony
• CakePHP

If the scope of this proposal is not only JavaScript and TypeScript projects, I think this should be considered.
Even if this proposal only targets JS/TS, it might cause trouble if the developer mixes their PHP and frontend code in the same repository.

3. package.json: causes more conflicts

In addition to remcohaszing's points, I also heard an opinion to avoid writing configs in package.json.

If you write all the configs in package.json in the team projects, it causes a lot of Git conflicts because many people frequently update package.json.

I think the use of the .config convention comes down to a few key reasons:

Developer Habits & Familiarity

Even though we might usually associate ~/.config with system setups (also potentially hidden), it’s a pretty natural fit for project-level configurations too. We’ve also been using hidden files like .namerc for a long time without much fuss. Most modern file explorers or editors are set up to display hidden files when needed. Most devs I know keep hidden files showing at all times.

Established Legacy and Tooling (in JS/TS)

For years, tools like cosmiconfig have embraced the .config directory approach, creating a long legacy within the JavaScript/TypeScript world. This historical support means that many projects—and by extension, developers—are already familiar with and expect that configuration can reside in this directory.

• Cosmiconfig:

  • npm dependents
  • GitHub dependents
  • Big names like Lerna, Puppeteer, Stylelint, ShadCN, and SVGR are using this.

• Lilconfig:

  • npm dependents
  • GitHub dependents
  • Includes cssnano, oclif, lint-staged, size-limit, playwright-test, typesync, etc

• C12:

  • npm dependents
  • GitHub dependents
  • It powers many UnJS tools like Nuxt, Nitro, OpenAPI TS, and Trigger.dev.

My personal opinion

I believe standardization is important and I do consider .config a defacto standard in the JS/TS community. Changing something already fairly common will lead to an even more fragmented ecosystem for years until every dependency updates.

I totally understand the perspectives being shared here—especially from folks coming from other language ecosystems where config structures might be opinionated differently. Historically the JS/TS ecosystem is by far the most config and tooling heavy—for better or worse—which is why I'm giving their existing conventions a lot of weight.

I fully agree package.json is not the right place. If it did have to change, I would lean more towards _config or _configs than .configs—simply because it's visually harder to quickly see the difference between the new plural and legacy non plural. Overall however I'd advocate for continued use of the .config directory.