Skip to content

Recommendation for tooling config file location/format #71

@vjpr

Description

@vjpr

The root dir of most Node projects quickly becomes cluttered with tooling config files. If you look at a single-line Node package, you will often find 10+ files just for the tooling config in the root dir.

Another downside is that it is very difficult to share standard config because there are so many different files that need to be in different locations, and they all use custom resolvers.

I think the goal should be to allow common tooling config to be shared and easily overridden with as few files as possible.

This is very difficult because some tools allow configuring the config file location, but most do not.

Existing standards

There are some libraries such as cosmiconfig (used by prettier) that provide a prioritized way to locate config files. (.mytoolrc.js, mytool.config.js, package.json#mytoolConfig). The naming conventions it uses seem to be supported by most tools...however the way that import resolution happens is very non-standard (see eslint for example).

XDG Base Directory Spec for dotfiles under a single .config dir is interesting.

There is currently a convention to use a key inside package.json which centralizes the config, but unfortunately this does not allow JS code or the use of imports which is quite common these days.

Recommending declarative or serializable configs would be something else that would be useful. That is, all config should be able to be evaluated to json, and the import statements are just used for importing packages.

Ideas

Here are a few ideas of conventions for centralizing/standardizing tooling config:

a. Have a folder called tools that is searched for config files. Possible recommend a sub-folder with the same name as the tool.

b. Single file (e.g. ini format) that allows the locations of each to be configured.

c. Recommend a tools.config.js file that would be similar to the way package.json is used but allows JS code.

tools.js

// Have a lint rule that disallows top-level imports because this would be a performance problem because all configs would be loaded for any tool.
export default {
  eslint: async () => {
    return await import('@org/eslint-config')
  },
  prettier: async () => {
    return await import('@org/prettier-config')
  }
}

d. For monorepos, it would be useful if all the dependencies for tools could be centralized in a single package that could be shared.

monorepo
  package.json
  packages
  tools
    package.json
    babel
      babel.config.js
    eslint
      eslint.config.js
    ...

Also regarding monorepos, a few of the tools rely on their config file location to signify the root of the monorepo. Like pnpm-workspace.yaml, babel.config.js, tsconfig.json. Having a standard way to indicate a monorepo root might also be useful.

e. Standardize package.json#config.{tool name}] for storing declarative configs.


Not sure node-tooling is the right place to drive this, and maybe its best left in the user-land, but I'd be interested in where the best place to have this discussion would be, to see if there is any interest.

But I do think the idea of being able to add a single file to your project or package to get a complete toolchain (linting, formatting, transpiling) is quite appealing.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions