Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recommendation for tooling config file location/format #71

Closed
vjpr opened this issue Jun 6, 2020 · 2 comments
Closed

Recommendation for tooling config file location/format #71

vjpr opened this issue Jun 6, 2020 · 2 comments

Comments

@vjpr
Copy link

vjpr commented Jun 6, 2020

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.

@vjpr vjpr changed the title Recommendation for tooling config file location Recommendation for tooling config file location/format Jun 6, 2020
@dominykas
Copy link
Member

dominykas commented Jun 25, 2020

I've been thinking this for quite a while now! Yes!

I think I prefer a folder. I have not considered a single file or thought about it deeply, but my gut is that I don't like large files... So there'd still be a folder with smaller files to require().

So I'd vote for a .config at the repo root. Ideally the apps could walk up the tree to find the nearest .config and fall back to ~/.config or smth like that. It could be up to the app to decide to use the nearest one or merge the local and global ones (although this would definitely not make the support any easier).

@boneskull
Copy link
Collaborator

Closing in lieu of #79

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants