for the next major release: drop uncommon variants of nest cli config file

[micalevisk]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe it

as of now the CLI supports the following configuration files:

nest-cli/lib/configuration/nest-configuration.loader.ts

Lines 28 to 33 in 26fc598

	: this.reader.readAnyOf([
	'nest-cli.json',
	'.nestcli.json',
	'.nest-cli.json',
	'nest.json',
	]);

personally, I never saw a project with a different configuration file other than nest-cli.json. And there is no mention in the docs site about the others.

and so I'm suggesting to remove the support for the following configuration file names:

• .nestcli.json
• nest.json

The .nest-cli.json seems fine to me because users might want to hide the configuration file (??)

For the .nestcli.json one there are few really old occurrences on public GitHub: https://github.com/search?q=path%3A%2F%5E%5C.nestcli%5C.json%24%2F&type=code

Describe the solution you'd like

only supports nest-cli.json and .nest-cli.json as NestJS's CLI configuration files.

Teachability, documentation, adoption, migration strategy

• since the others names are not mentioned in the current version of the docs, I think that we should just add a minor note on the migration guide (from v10 to v11)
• update the JSONSchema definition at https://github.com/SchemaStore/schemastore

What is the motivation / use case for changing the behavior?

1. avoid name collisions with other framework/tooling. If we search for the nest.json one, for example, we can see a bunch of files on GitHub that are not related with NestJS: see here
2. avoid confusion for when we have multiple config files in the project
3. keep a more standard setup across different nestjs projects
4. avoid the need of introducing more notes in the docs pages where we are mentioning "nest-cli.json" but not the others

[kamilmysliwiec]

Sounds good to me, let's do this

[micalevisk]

I'll open a PR to address this