cosmiconfig VS main

Meanwhile, formats have been evolving (JSON5, YAML), config entry points are constantly changing. These fluctuations, fortunately, were covered by tools like the cosmiconfig.

I've heard of cosmicconfig, which I think allows you to put most of your config files in a single .config folder. I've never used it though.

There is a fantastic library davidtheclark/cosmiconfig: Find and load configuration from a package.json property, rc file, or CommonJS module that does all the tedious work for you.

info on XDG: [the XDG spec](https://standards.freedesktop.org/basedir-spec/basedir-spec-...)

tools that respect XDG, for fellow JS CLI developers:

- https://github.com/davidtheclark/cosmiconfig Find and load configuration from a package.json property, rc file, or CommonJS module. [Check `searchPaths` to implement XDG spec compliance.](https://github.com/davidtheclark/cosmiconfig/issues/152)

- Sindre's libraries use [`env-paths`](https://github.com/sindresorhus/env-paths#pathsconfig) to get paths compliant with this.

- https://github.com/sindresorhus/conf simple config storing (maybe try [conf-cli](https://github.com/natzcam/conf-cli) to manipulate if needed) the successor to [configstore](https://github.com/sindresorhus/conf#how-is-this-different-f...)

- https://github.com/jonschlinkert/data-store conf like datastore but in the shclinkerverse

cosmiconfig - Reads configuration from a file. It searches for many file types and file names, and even supports defining config in the package.json file. Very customizable, it's an awesome library very flexible both for the app developer and for the app user.

Here's an example of a test that covers a lot: Let's say that you have a view that shows a list of users. To get those users you would most likely have a backend that has some API. You can request that API with Postman, that way you know that your request is valid, and you get a very realistic response (assuming this is a test environment or whatever. Just don't use production data). Then you use something like MockServer and set up the request as expectation and the response as what should be returned. After that, you can write a test that verifies that the correct number (with some tactically chosen verification of values) of users show up in the list. Now you have a test that covers a huge portion of the codebase, while being very user-centric and easy to maintain.

@mocks-server/config - It allows to define configuration options, and it reads environment variables and uses cosmiconfig and commander under the hood to provide values to them.