when should shims of third-party binaries resolve to local dependencies?

[dherman]

My original design was that shims for third-party binaries would always resolve to a local dependency if it's present (similar to how npx and other tools work). My intuition was that I never want a global binary if there's a local one available. In conversation with @stefanpenner he suggested that this might lead to surprises where you thought you were calling a global tool and didn't know that a local project had overridden it.

So a few alternatives would be:

1. Local binaries always win
2. Local binaries from direct dependencies (not transitive dependencies) always win
3. Local binaries only win when explicitly opted in through a configuration entry in the project's Notion config (e.g., "bin": ["gulp", "tsc", "eslint"])

ISTM (1) is a non-starter -- I really don't think anyone wants a transitive dependency's binaries to be there, and in fact npm is considering incompatibly changing that behavior in a future version of npm. (This is especially egregious if a transitive dependency depends on npm itself!)

So I think it's really between options (2) and (3).

[dherman]

I think I still prefer (2), but I think the strongest argument for (3) is e.g. when a package depends on a package that provides a binary with a common command, like how node-which provides a which command. This would mean suddenly when you're in unix and sitting in a project that happens to use that as a dependency, you're no longer getting the standard unix which.

[mikrostew]

I just put up an RFC for package executables that implements option (2): #21