Support for using a custom "node:fs" implementation

[DavidAnson]

Sometimes, node:fs is not available or is not relevant and it is nice to be able to use tools like this with a custom file system wrapper. For reference, globby allows this and the VS Code markdownlint extension uses it to run on the web and with remote file systems.

[fabiospampinato]

Something like that should be enabled, but allowing a custom "node:fs" implementation feels a bit like a hack 🤔 I'm not sure what a better alternative with no downsides would be though.

I don't see this happening in the near future, but you may want to look into bundling the package in a way that you can override what gets loaded when importing "node:fs" via the bundle.

[DavidAnson]

While I wouldn't say this is common, it is a pattern that is used by various packages like this. It provides a nice abstraction where a package can be written to assume the standard file system API, but consumers with special requirements can pass in an alternate implementation or a wrapper and it magically works. Ideally, for things like this the package should depend on as few file system functions as possible.

[DavidAnson]

By the way, I'm interested in exploring this package as an alternative to globby for markdownlint-cli2, but I need file system abstraction for the Code extension. Globby has that, though it has a couple of issues at present.

[fabiospampinato]

Yeah I've seen it used by some other packages also. At the moment I don't feel like committing to this, because it still kinda feels like a hack to me. Like most of the times I try to write code that works in the browser also, when that's not possible I assume I have access to Node's APIs, this would be some kind of hybrid solution I don't particularly like, though I don't see a much better way of doing it either.

[fabiospampinato]

Stupid-not-so-stupid way to get this to work in the meantime: you can just bundle the entire library and replace from "node:fs" and from "node:fs/promises" with your shim for this, if you don't need a different instance of this with each call of the library or something like that.

[DavidAnson]

I already play some slimy tricks in the build to create something that runs in web worker context... :) You're not wrong here, but I don't think I can easily write tests for the technique you propose whereas passing a wrapper is quite easily unit tested. (I even unit test my mock!)

https://github.com/DavidAnson/markdownlint-cli2/blob/main/test/fs-mock.js