feat: support custom fs

[43081j]

Adds a new fs option for specifying your own fs implementation.

Fixes #134

[43081j]

this is purposely explicit rather than just FSLike = typeof nativeFs since the fs module has all sorts of exports (both types and actual exports) which we don't want to have to stub out to satisfy the type when bringing our own fs-like object

[SuperchupuDev]

was about to start working on this, then saw you had already implemented and pr'd it!! thanks a lot. hopefully @thecodrr can review soon 🙏

[michaelangeloio]

This is awesome!

[SuperchupuDev]

it truly is

[benmccann]

just a style question probably for @thecodrr, but I wonder if these two lines should be combined into a single line

[benmccann]

I noticed there aren't any docs being updated as part of this PR. That would probably be nice to add

[SuperchupuDev]

this probably needs a rebase so that it can get formatted with prettier 👀

[43081j]

i have rebased and run the formatter

@thecodrr can you take another look when you get time?

[SuperchupuDev]

@43081j it looks like this needs a rebase again 👀

[thecodrr]

We can't import fs anywhere in the project (importing the types are okay since they are stripped). It needs to be imported conditionally otherwise anyone trying to use fdir outside node won't be able to use it - defeating the whole point of this PR.

Perhaps we can use require but if we generate esm builds, that won't work afaik. await import is also not an option since build options are synchronous.

[43081j]

we already have this problem - the walker imports path

are we sure that's the point of this PR? afaik nobody is expecting to run fdir in browsers (which is the only place that doesn't have path and fs, since all node-like runtimes provide them)

if we want to avoid depending on any node built ins, its a bigger job since we'd need to pull in pathe or something (agnostic path library) instead of path

@SuperchupuDev what does tinyglobby need this for?

[SuperchupuDev]

We can't import fs anywhere in the project (importing the types are okay since they are stripped). It needs to be imported conditionally otherwise anyone trying to use fdir outside node won't be able to use it - defeating the whole point of this PR.

Perhaps we can use require but if we generate esm builds, that won't work afaik. await import is also not an option since build options are synchronous.

we can try to use require for conditionally importing it like we already do with picomatch. tsdown (the tool thats used in the dual build pr) automatically defines a require function with import { createRequire } from 'node:module'; createRequire(import.meta.url) for esm builds

[SuperchupuDev]

we already have this problem - the walker imports path

are we sure that's the point of this PR? afaik nobody is expecting to run fdir in browsers (which is the only place that doesn't have path and fs, since all node-like runtimes provide them)

if we want to avoid depending on any node built ins, its a bigger job since we'd need to pull in pathe or something (agnostic path library) instead of path

@SuperchupuDev what does tinyglobby need this for?

iirc the library that requested the feature wants it so that they can use when globbing their custom fs wrapper that does caching

[43081j]

yeah lets not go down a rabbit hole trying to hack in some require calls 😅

fdir currently relies on Node libraries (it imports path)

we can do this with fs too and satisfy the feature request with the PR in its current state afaict

nobody can use fdir in a browser right now without bundling it. so we haven't changed that

let me know if im missing something though

[SuperchupuDev]

i agree, not using require would be ideal

[thecodrr]

@43081j can you resolve the conflicts so I can merge this?

[43081j]

should be all good now 👍