Prefer local install

[jamestalmage]

Fixes #571

[sindresorhus]

Can you mention the behavior in the readme? That the globally installed CLI uses the local version if any.

[jamestalmage]

I am wondering about our choice here. np is a bit different than AVA or XO. If I run an old local version of XO a few times, I'll get the warning to upgrade, and can make my choice.

If the local project has an outdated version of np - by the time I notice, it may have done things I wasn't expecting. Especially if I am used to a newer version of np.

With AVA and XO, it's not a big deal. np does things that aren't as easy to undo.

[sindresorhus]

I don't think this should be logged each time. You can use util.debuglog.

[sindresorhus]

by the time I notice, it may have done things I wasn't expecting

For example?

[jamestalmage]

For example?

You keep adding new features / checks all the time (like waiting for GitHub Actions to complete, etc). If I have come to rely on some new feature, and open up some old project - np is going to silently revert and not run those extra checks.

I am just wondering if we need the added auto-magic convenience on a module I use 10x-20x less than xo or AVA.

[sindresorhus]

If I have come to rely on some new feature, and open up some old project - np is going to silently revert and not run those extra checks.

I think it's more important to use the correct np than to miss out on some checks. This is especially important in case np does breaking changes to any of the config.

[jamestalmage]

I think it's more important to use the correct np than to miss out on some checks. This is especially important in case np does breaking changes to any of the config.

Oh, totally agree. My point was that maybe we could just enforce it with a failure of the global CLI, instead of automatically running the local one. That way the user is making the conscious choice to use the older local np, or upgrading the local np before releasing.