Consider supporting configuration file names of the form markdownlint-cli2.config.jsonc by default (follows ESLint)

[Zamiell]

As per the README, markdownlint-cli2 supports the following names for configuration files by default:

• .markdownlint-cli2.jsonc
• .markdownlint-cli2.yaml
• .markdownlint-cli2.cjs or .markdownlint-cli2.mjs
• .markdownlint.jsonc or .markdownlint.json
• .markdownlint.yaml or .markdownlint.yml
• .markdownlint.cjs or .markdownlint.mjs

However, over the past 10 years or so, there has been a movement in the ecosystem to have lint tools standardize on a naming convention of foo.config.js. The "big 4" are ESLint, Prettier, Jest, and CSpell.

• The default config file name for ESLint is "eslint.config.js", as shown in the ESLint configuration documentation.
• The default config file name for Prettier is ".prettierrc", as shown in the Prettier installation documentation. However, it supports "prettier.config.js" out of the box without any additional configuration, as shown in the Prettier configuration file documentation.
• The default config file name for Jest is "jest.config.js", as shown in the Jest configuration documentation.
• There does not seem to be an officially recommended file name for the CSpell configuration file. The CSpell configuration documentation shows "cspell.json" at the top of the list. But much like Prettier, it has first class support for "cspell.config.js" out of the box without any additional configuration.

Other popular tools like Knip also support "knip.config.ts" automatically.

Edit - After making this post, I found yet another example in this very repository. =p

Thus, in order to match the way that the ecosystem is going, I propose that markdownlint-cli2 also supports the following file names by default:

• markdownlint-cli2.config.jsonc
• markdownlint-cli2.config.yaml
• markdownlint-cli2.config.js
• markdownlint-cli2.config.cjs
• markdownlint-cli2.config.mjs

[DavidAnson]

I outline my goal to avoid redundant file names here: #392

Related, I prefer - and think other people should prefer - a data file for configuration like JSON or YAML over a code file like JavaScript that needs to be parsed and run. This is a security stance, though I acknowledge it doesn’t eliminate all risk.

[Zamiell]

I outline my goal to avoid redundant file names here: #392

Then I propose that Markdownlint changes the default file names in the next major version. (And removes support for the existing ones.)

(Side note - this package doesn't seem to have released a major semveryet, so I guess people can expect breaking changes in minor semver?)