-
Notifications
You must be signed in to change notification settings - Fork 16
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
Comments
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 So I'd vote for a |
Closing in lieu of #79 |
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 waypackage.json
is used but allows JS code.tools.js
d. For monorepos, it would be useful if all the dependencies for tools could be centralized in a single package that could be shared.
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.
The text was updated successfully, but these errors were encountered: