Find XO config based on linted file path

[pvdlg]

fix #331, fix #279, fix #330, fix #420, fix #65

This change the way to load the XO config files. Instead of looking for the config in directly cwd we now search for a config file starting from the directory of each linted and by walking up parent directories.

The config files supported are now: pacakge.json, .xorc (JSON only), .xorc.json, .xorc.js, xo.config.js

This PR will help to implement #373 as we can now build a different config per file mode easily. That will allow us to apply the Typescript rules only to the .ts/.tsx files.

A few other things incidentally added by the PR:

• A way to override the default ignores #65 is now fixed
• Workspaces Broken vscode-linter-xo#58 should be fixed without any changes in vscode-linter-xo
• lintFiles is now completely async allowing to parallelise looking for config files (async) with building/merginf config (sync)
• Reorganized the code a little bit for clarity as the files and function started to be quite large
• Replace multimatch with micromatch as it's the library used by globby which is already in the dependency tree

---

IssueHunt Summary

Referenced issues

This pull request has been submitted to:

• #65: A way to override the default ignores
• #330: Support an external config file instead of just package.json config

---

IssueHunt has been backed by the following sponsors. Become a sponsor

[sindresorhus]

Yay! This is really awesome 🙌

---

The config files supported are now: pacakge.json, .xorc (JSON only), .xorc.json, .xorc.js, xo.config.js

Can we make it:

• .xorc => .xo-config
• .xorc.json => .xo-config.json

And maybe drop .xorc.js since there's already xo.config.js?

[sindresorhus]

And maybe drop .xorc.js since there's already xo.config.js?

Hmm, I guess it can be useful if you want to hide it. But should be .xorc.js => .xo-config.js

[sindresorhus]

#65 is now fixed

🎉 Could you add a short readme example to show the user that this is possible?

[pvdlg]

Can we make it:

• .xorc => .xo-config
• .xorc.json => .xo-config.json

That's really common among JS projects to have the config files being based on the package name (without a -config) for example .prettierrc or .eslintrc and not .prettier-config or .eslint-config. I think breaking from this convention would be confusing and error prone for users.

It would also create a discrepancy between the package.json property, the json files and the JS files.

[pvdlg]

🎉 Could you add a short readme example to show the user that this is possible?

Added a Tips

[sindresorhus]

That's really common among JS project to have the config files being based on the package name (without a -config)

And it's still based on the package name. We're just replacing rc with -config for clarity.

I just don't like the rc suffix. It only makes sense if you know what https://github.com/dominictarr/rc is, and I've been in Node.js for years and I don't really know what rc stands for. "resource configs"?. And by not having a separator, it's not always clear what it is. .xorc, reads to me as xorc, not xo rc. What if the package name was co. Then the file would be .corc.

I think that breaking from this convention would be confusing and error prone for users.

I honestly think the convention with rc is more confusing than not following the convention. xo-config makes it totally clear what it is. No questions asked. Imagine a newbie getting into JS, cloning a random project, and seeing a .xorc file without knowing what XO or rc is. Do you think they immediately realize it's config file?

It would also create a discrepancy between the package.json property, the json files and the JS files.

The package.json property is xo, the current filename is xorc. There's already a discrepancy. -config is not any more of a discrepancy than rc.

[pvdlg]

Made the change for config file name

[sindresorhus]

There's a slight regression in the code coverage: https://coveralls.io/builds/28770195/source?filename=lib/options-manager.js#L261

Otherwise, this looks good to me. When merged, should I do a new release or do you plan other changes soon?

[pvdlg]

There's a slight regression in the code coverage: https://coveralls.io/builds/28770195/source?filename=lib/options-manager.js#L261

That was on line 303 before and wasn't tested either.
I improved the test coverage for the part I changes that changed

[pvdlg]

Otherwise, this looks good to me. When merged, should I do a new release or do you plan other changes soon?

I'm working on the Typescript support today. Not sure if I'll finish by the end of day. If I don't open the PR today, it will probably take a few days.

[sindresorhus]

Weird, not sure why Coveralls said the coverage fell on that line then 🤷‍♂️

[sindresorhus]

I'm working on the Typescript support today. Not sure if I'll finish by the end of day. If I don't open the PR today, it will probably take a few days.

Sounds good. Then I'll wait. Take your time. I was really just wondering whether anything would happen in the next few weeks for it to be worth waiting for.

[sindresorhus]

Thank you so much for working on this. This is such a great improvement 🙌