building on top of fsx

[boneskull]

So, if I want to write a library that leverages fsx, how would I do so? What does that look like? Say, a glob implementation.

I don't mean to do something like monkeypatch fsx's API. Rather, this would be a library that accepts (is configurable with, somehow) an Fsx instance (?) and uses that instance to do its work.

It appears that fsx-core exports the Fsx class, and something like fsx-node provides an instance of that class. Is this corrrect? Is it reasonable for a library, then, to be instance-and-Impl agnostic?

Is there an example of such a thing?

[nzakas]

It appears that fsx-core exports the Fsx class, and something like fsx-node provides an instance of that class. Is this corrrect? Is it reasonable for a library, then, to be instance-and-Impl agnostic?

I'd suggest you check out the source code for each of the runtime packages, as I think that will answer your questions about how to use the Fsx class.

For the second question, it is possible to be agnostic as to the implementation as long as you're passing an fsx object around. (You can't just grab any old fsx object from a package because it might not be the one you've imported.)

[boneskull]

Right. Is this the reasoning for the "singleton" nature of it, then?

[nzakas]

The singleton nature is to make it similar to doing import fs from "fs", which has the same issues of a shared singleton across everything in the application, including third-party modules. I figured that would be the easiest starting point for most folks.

Each runtime package also exports a constructor that can be used to make your own instance (NodeFsx, for example, from fsx-node).

I was unwilling to place a bet on which pattern would be most useful to folks, so I provided both. :)