feat: support monorepos by allowing nested folders to act as the xo root folder.

[kiikoh]

This comes up for me if I want to have a react project in a client folder as well as a server folder both open, and using different configurations.

I think the expected behavior should be to walk up the folder structure from the file that is currently open stopping at the first package.json it reaches.

[spence-s]

How do you handle this with the xo cli? This is just not the way xo works. -- the way to handle a monorepo in the documentation is to put a single config at the root and use overrides. see https://github.com/xojs/xo#monorepo
--- I think your use case would need to be better supported by the cli for me to support it here, but if you feel differently I am open to ideas and will accept PRs.

[kiikoh]

OK, I think you are right here, XO was giving me a hard time as well, it might be an issue for XO, or not at all, wasn't aware of the monorepos

[kiikoh]

Hey, I've tried working with the monorepos and I can't seem to find the correct usage of it anywhere online. How can I set up xo in the root of the monorepo, and then extend the configuration in the "app" level package.json's? Basically, I have a react and express server and I want to have the react plugins for the front-end only @spence-s

[papb]

Hello, I am not in the real situation described here, but after reading the thread I wonder why you started talking about monorepos. Consider a much simpler example: you have two completely unrelated Git repositories of Node.js projects that happen to be cloned next to each other in a folder in your PC. And then you opened only one VSCode window, on this parent folder. Sometimes you work on project A, sometimes on project B, but always with this same VSCode window, for whatever reason. What OP said should just work:

I think the expected behavior should be to walk up the folder structure from the file that is currently open stopping at the first package.json it reaches.

And for this case, to me, the question of "How do you handle this with the xo cli" is answered with: there's nothing to handle, each project has its repository and will run xo from its CI normally.

What am I missing?

[kiikoh]

Yeah, I agree I was not completely satisfied with the answer I received either, I still haven't figured out a way to get it working exactly as I'd have liked it to.

[spence-s]

EDITED: sorry guys - I gave a bad answer here last week with some wrong information and was pretty snarky about it as well. After further review, I think the bugs and use cases here are valid. There are some bugs here with both the extension and possibly with xo itself causing these monorepo use cases to be not so user friendly.

I am going to investigate this more and see if I can come up with some better monorepo development experiences for xo and the extension in the near future and try to be clear about it in the documentation.

[spence-s]

release 3.12.0 now allows for xo to be resolved from anywhere and is no longer needed in a workspace. All it needs is to find a parent directory where xo is installed.