6

I have always placed different "tooling configurations" in their own files in my front-end projects.

For example: babel in babel.config.js, jest in jest.config.js, eslint in an .eslintrc.json, etc.

I have noticed recently however that it is possible to place many of these configurations directly in a projects package.json file instead.

I did some digging around online and asked a few colleagues but no-one can seem to give me a definitive answer as to why one might prefer one approach over the other.

Is it purely a matter of preference?

Andrew Hill
  • 2,165
  • 1
  • 26
  • 39

3 Answers3

10

My suggestion is to avoid stuffing package.json with custom configs mainly for two reasons.

First is regarding developer expectations. Putting yourself in the position of a person that is just getting off with JavaScript and NPM ecosystem, you see something that's not documented, at least not where you expect it to be. This kind of experience could easily drive folks away especially if they come from more strict developer platforms and languages.

Second, keyword collision or more importantly the thought of such being possible. We don't expect NPM to consider not using some keyword in the future just because some shiny new lib is using it too, do we?

On the other hand having dedicated files for babel, browserlist, postcss is such more simple, self-explanatory approach and every single of those projects already recommends using dedicated files for configurations.

Z. Zlatev
  • 4,757
  • 1
  • 33
  • 37
  • Can relate with this, it's a bummer to see tools reusing package.json for their own configs. It can save some time, but not worth it. – hazardous Dec 18 '19 at 05:37
5

Here are the Pros and Cons of package.json configs IMO:

Pro package.json becomes a single source of truth for your apps packages, scripts, and, now, configs. It's a one-stop for everything related to your app.

Pro It declutters your root directory. Having a separate config file floating around for all your different packages gets messy.

Con Keyword collision possibility. If Node comes out with a new keyword that happens to match that of an existing package config, then you have to either not use the keyword or move the config to a separate file.

Con Most package documentation references the separate config file in their examples. It could be confusing for troubleshooting or new team members.

Con Your package.json file could get HUGE. And if many configs are managed, the potential for a merge conflict with another team member increases greatly.

Overall it comes down to personal preference. There are some tools like husky (https://github.com/typicode/husky) that put config in package.json by default. Our team does a combination of both.

colefner
  • 1,812
  • 1
  • 16
  • 11
  • 1
    One reason against using package.json is .json doesn't support comments. Config in js, ts, yml, xml, ini, etc. all have a comment syntax. – None Oct 29 '20 at 20:52
1

I think there is no benefit you will make the package.json file more complicated and there is no reason for that if you make separate files you make declarative and people understand the project better

Mohammad Ameer
  • 49
  • 2
  • 7