Support `.markdownlint.js`

[Mister-Hope]

.markdownlint.js should be supported and its file type (cjs/esm) should be based on current package.json.

This is a problem because I need to extra declare .markdownlint.mjs / .markdownlint.cjs in eslint and typescript config files in all my repo to have it included, while all other files are js.

Anyway its weird to have a .cjs file in cjs package and a .mjs file in esm package.

Other tools like commitlint eslint vite, ... all support this.

[DavidAnson]

The current behavior of ClI2 is deliberate. In my mind, the "js" extension should no longer be used because it is ambiguous.

That said, I am curious if the behavior in other tools is deliberate or accidental - and whether they had to write code to support it.

[Mister-Hope]

In my mind, the "js" extension should no longer be used because it is ambiguous.

Not meaning to be rude, but check your current repo plz? Most of the popular repo is not written in full .mjs or .cjs, then where does the point come from?

In a type: "commonjs/module" package, a .js is the same as .cjs/.mjs. Since all LTS Node.js already supports esm, we are not facing the early esm situation that a .js file from esm package might be parsed as commonjs by lower version of Node.js.

[Mister-Hope]

Some Refs:

• https://eslint.org/docs/latest/use/configure/configuration-files
• https://commitlint.js.org/reference/configuration.html
• https://prettier.io/docs/en/configuration
• https://stylelint.io/user-guide/configure
• https://vitejs.dev/config/
• https://github.com/lint-staged/lint-staged#configuration

[Mister-Hope]

Maybe you can use this pkg directly: https://github.com/cosmiconfig/cosmiconfig

[DavidAnson]

The point is that you (or an editor) cannot tell from looking at JS extension what type of file it is. What's more, copying that file from one project to another may not work because the projects are configured differently. None of that is an issue with the CJS or MJS extension.

While it is less obvious in this repository, I use CJS or MJS for new files except where existing files already have the JS extension. That means this tends to happen most in new test files and you can see that in other repositories I maintain. The new esint.config.mjs in next branch is a good example.

I will have a look at some of the links you sent, but I do not think this behavior raises to the level of introducing an entirely new configuration system. As you note above, everything works fine today - the issue is just that you do not want to deal with different extensions.

[Mister-Hope]

Yes, everything could work fine under current package, but as all popular lint tools support js config file and have its type auto-inferred (see docs I provided earlier), then it could be a kind of "common feature lacking” for the package itself.

[Mister-Hope]

eslint, prettier, stylelint and lint-staged support all cosmiconfig format (eslint up to v8, since v9 introduce flat config and it's a breaking change, a script config file is required)

rollup, commintlint and vite are even more aggressive, they all preprocess the config file, so esm config file is even allowed with .js in a cjs pkg.

So I have to say that there is more likely to be a lacking feature here.

[Mister-Hope]

The point is that you (or an editor) cannot tell from looking at JS extension what type of file it is.

Solution can be found in the ref I provided

What's more, copying that file from one project to another may not work because the projects are configured differently.

I don't think this should be an issue, if a people just want to quickly re-use an existing file and the type is different between 2 projects, he just need a rename or a export default | module.exports = rewrite . We are actually supporting cjs and mjs extension for this case, and in most cases (excerpt eslint), we are not expecting users to have imports in these config files.

[DavidAnson]

I already do not support JSON and YML extensions for the new options file format (preferring JSONC and YAML) for simplicity and I think this is similar. Except here there is the added complexity of JS meaning CJS and/or MJS depending on where the file lives.

Where we differ is that I don't think this is a "feature" because it doesn't enable any unique behavior. I see why people think it is a "simplification", but it also introduces ambiguity and complexity that does not need to exist.

I will leave this issue open for comments and to think about more.