I think this is still a bit risky. The fix depends on searchStrategy: 'project' walking past a nested package.json to find the parent config, but cosmiconfig documents that strategy as stopping once it finds a package.{json,yaml}. It happens to work with the current implementation, but if cosmiconfig changes to match its docs, this regression comes back.

It also means XO can now pick up an unrelated ancestor config above the actual project, which feels broader than the issue needs. I think we should either avoid relying on this undocumented behavior, or add an explicit test that shows this wider ancestor lookup is intentional.

I suggest opening an issue on cosmicconfig to clarify.

Thanks, agreed. I removed the searchStrategy: 'project' change and restored the bounded cosmiconfig search.

The follow-up now uses an explicit fallback only for a parent package.json that declares workspaces matching the nested cwd, so XO can pick up the intended monorepo root config without relying on cosmiconfig walking past a nested package.json or grabbing an unrelated ancestor config.

I also added a regression test for the negative case where an ancestor package.json has xo config but does not declare the nested package as a workspace.

Ran:

• npm run build
• npm run test:setup && npx ava dist/test/resolve-config.test.js
• node dist/cli.js lib/resolve-config.ts test/resolve-config.test.ts
• npm test
• git diff --check

I did not open a cosmiconfig issue for now because this PR no longer depends on that undocumented behavior.