how to do feature detection

[Trott]

Ref: #22302

We need to make a decision about how to do feature detection so we can land the mkdirp implementation in a release. (Right now, it's in master, but no releases.)

@nodejs/tsc

Sorry this is a stub right now, but feel free to add information so I don't have to come back and do it later.

[Trott]

For mkdirp, I'm in favor of making it its own function so users can check for existence of fs.mkdirp. But that doesn't answer the question going forward because a separate function is not always sensible

[jasnell]

separate function is not always sensible

I think this is a more important distinction that it may first appear. Are there reasonable general heuristics we can apply to this choice?

[bengl]

I still think having an external module to tell whether a feature is available or not is the best approach, because it can potentially be used on older versions of Node without much issue. In addition, keeping the functionality external frees us to do whatever is most sensible when designing new APIs or adding functionality to existing APIs.

See my comment on the other thread, where I mocked up a module that would work like this.

[targos]

I also think it's better to keep this outside of core. The best way to know anything about a feature (is it here? is this new option available? has the behavior changed in this case?) is to look at the history in the documentation and compare with the current version number.
It's not necessary to pull in the semver module (and I'd say it would be a mistake because of how satisfies() handles pre-releases). What we can do to help a "core-features" module (and probably other packages that already depend on semver just to check the major/minor/patch numbers) is to expose the individual numbers in separate properties.

[boneskull]

As I mentioned in the other issue, userland libs will be where most of the version/feature detection happens.

Userland can perform feature detection using whatever method it deems best.

But reading docs across multiple release lines--manually sifting back through old versions-- to determine when a feature appeared seems painful.

Node.js can help userland make those decisions by providing a single reference document showing in which version a feature or significant API change appeared.

[boneskull]

Ultimately, the most important thing to me is that we ship the new fs.mkdir option as submitted, because this is the most natural API.

IMO, feature detection isn't a convincing reason to use fs.mkdirp. That's just punting on a feature detection strategy.

[Trott]

@boneskull How would you feel about shipping the API as it is but also including an fs.mkdirp() that is a wrapper of fs.mkdir() that sets the recursive option? I'm not a fan of creating multiple ways to do the same thing, but there's precedence for that all over JavaScript and it does provide simple feature detection for recursive mkdir() as well as recursive rmdir() if we do something similar there.

We still have to decide if feature detection should be done the way @MylesBorins proposes or the way @bengl proposes or both or some other way. But it does free us to move forward with releasing recursive mkdir() while we figure that out.

[MylesBorins]

I'm sorry for being difficult but I am -1 on including mkdirp, specifically I find adding a new api for recursive apis to be untenable and unscalable

[targos]

@MylesBorins What do you mean? Do you want to revert #21875?

[MylesBorins]

no... I am a huge +1 on fs.mkdir with the recursive flag. I am minus one on the alias to fs.mkdirp

[boneskull]

@Trott who else needs to be looped in here?