Skip package.json files with "xo": false

[ekmartin]

This makes xo continue its folder recursion upwards whenever it finds a package.json where xo is set to false - see discussion at sindresorhus/atom-linter-xo#37 (comment).

There's one issue though, since pkg-conf uses Object.assign here there's no way to differ between false and an empty object - which results in this test failing. Any ideas?

[sindresorhus]

Maybe we can add a Symbol to the returned object of whether the original value is false? We could then add a method like pkgConf.isFalse(returnedObject) to check it, similar to the pkgConf.filepath() method.

[sindresorhus]

Actually, would be better to add an option in pkgConf to indicate that it should continue when it's false. That way we can contain all the logic in pkgConf instead of here. Could be useful for other tools using pkgConf too.

Suggested option name: skipOnFalse which should be false by default.

What do you think?

[ekmartin]

You're sure that's not slightly too opinionated? If you don't think so I can move the PR there instead.

Another option would be to only assign defaults in pkg-conf if !pkg.hasOwnProperty(namespace), and just return the actual value otherwise (i.e. here).

EDIT: Or, since you actually want the defaults to be set on objects as well, maybe check typeof pkg[namespace] === 'object' && pkg[namespace] !== null.

[sindresorhus]

It is too opinionated indeed. That's why it should be an option that is false by default. I considered what you're suggesting, but I want to optimize for the common case and always return an object, for convenience.

A pull request on pkg-conf would be lovely :)

[ekmartin]

sindresorhus/package-config#3

By the way, could this cause issues with https://github.com/sindresorhus/xo/blob/master/cli.js#L72? Since you could potentially get the wrong package.json from meow there?

[sindresorhus]

pkg-conf@2 is out, can you update this PR to use it? (Keep the tests. Those are useful as integration tests)

By the way, could this cause issues with https://github.com/sindresorhus/xo/blob/master/cli.js#L72? Since you could potentially get the wrong package.json from meow there?

No. Meow gets the package.json from find-up with cwd as __dirname, not from pkg-conf.

[sindresorhus]

Could you also document the ability to pass "xo": false to skip the package.json and continue searching upwards?

[ekmartin]

Done. I wasn't sure where to put the README section, so let me know if you'd rather have it somewhere else. In regards to the meow thing, wouldn't that mean that meow.pkg would become the package with "xo": false? Or am I missing something here.

Also, out of curiosity - couldn't you have released pkg-conf version 1.2.0? This doesn't seem to be a breaking change to me. Doesn't matter now though.

[sindresorhus]

Awesome. Looks great to me. I slightly tweaked the readme change on merge. Thanks for working on this :)

Need to go to bed now, but I plan on doing a new XO release tomorrow.

In regards to the meow thing, wouldn't that mean that meow.pkg would become the package with "xo": false? Or am I missing something here.

Meow is fetching the package.json here https://github.com/sindresorhus/xo/blob/master/package.json, not from process.cwd(), and it's not even using pkg-conf.

Also, out of curiosity - couldn't you have released pkg-conf version 1.2.0? This doesn't seem to be a breaking change to me. Doesn't matter now though.

Yes, but was already planning to do a major release with sindresorhus/package-config@d31b445 to reduce the amount of dependencies.

[ekmartin]

Great, thanks!

Meow is fetching the package.json here https://github.com/sindresorhus/xo/blob/master/package.json, not from process.cwd(), and it's not even using pkg-conf.

I see, makes sense.

Yes, but was already planning to do a major release with sindresorhus/package-config@d31b445 to reduce the amount of dependencies.

Ah, didn't see that you hadn't released that yet - makes perfect sense then!