Add ability to specify if looking for file or directory, only match files by default

[coreyfarrell]

By default directories will no longer match.

Fixes #33

[coreyfarrell]

I don't know TypeScript that well, could this be imported from locate-path (and if it can should it)?

[sindresorhus]

You can import it at line 1:

import {Options as LocatePathOptions} from 'locate-path';

And then extend it on line 2:

interface Options extends LocatePathOptions {

[coreyfarrell]

Actually Options is for using a matcher function where only cwd is accepted.

For the normal mode technically locatePath.AsyncOptions is supported, though I'm not sure we want TS to allow concurrency and preserveOrder to be used? For now my patch is using locatePath.AsyncOptions but can easily be switched to locatePath.Options.

Also instead of extending the locate-path options I just directly used them since this module does not add any new options.

[sindresorhus]

Hmm, just started thinking; when using findUp(matcher, [options]), should we support the type option then too? I don't really see any use-case of not knowing whether it's a directory or file up front. It would simplify existence checking as then you only need to check whether it exists, not also that it's the correct type.

// @sholladay

[coreyfarrell]

I was assuming that the matcher would deal with restricting the type, possibly by wrapping locatePath. Adapted from the test added in #28:

function matchUnicornParentPath(options = {}) {
  return async (cwd) => {
    const hasUnicorns = await locatePath(['unicorns.png'], { ...options, cwd});
    return hasUnicorns && cwd;
  };
}

console.log(await findUp(matchUnicornParentPath({allowSymlinks: false}));

[sindresorhus]

But is there any point in that flexibility? I can think of no reason to want either file or directory. Everything would be a lot simpler if the user could just define that upfront in the options like the normal findUp() method.

[coreyfarrell]

The normal findUp is adequate for my needs so I can't speak to the need for flexibility but the example matcher I gave is only capable of returning a directory (or undefined). I think it would be convoluted if this matcher failed to work without giving {type: 'directory'} to findUp. So my suggestion is not about flexibility, it's about what is responsible for the type check.

[sholladay]

But is there any point in that flexibility?

Personally, I am fine with it either way. I have never needed the flexibility mentioned above, however my thinking has been that the matcher function is responsible for the implementation details of how to match, hence the name, and in that case, findUp is merely responsible for walking the filesystem. This is how I've been thinking about the separation of responsibility.

That said, I also cannot think of a use case where it would be a problem for type to apply to the result. So I guess let's do it, for the sake of predictability, if nothing else.