whatwg/fs

[jimmywarting]

working with files in the same way in browser, Deno, bun.js and node should work seamlessly the same way.
That is one of the most annoying thing about switching from one env to another.

Now that the web browser have gotten support for an actual decent sandboxed filesystem called whatwg/fs then i wish i could move some things such as eslint into the browser and not having to depend on node's own internal fs for instances.

[jasnell]

We discussed this a bit on the call today. Currently, of the runtimes that are actively involved, Workers has no plans currently to implement these, there does not appear to be any activity with Node.js implementing these, and Deno is just starting to consider it but no concrete plans yet.

That's not to say that we shouldn't tackle file system at some point but I don't think there's nearly enough to include this in the current minimum common.

[jimmywarting]

OPFS that is part of the sandboxed surface in browsers allows for reading reading/writing files synchronous as well if you get the SyncHandle. but the sync handle is only available in workers (not from the main thread)

[wesbos]

Adding my thoughts, re: https://twitter.com/irvinebroque/status/1635754868936962049

I think bringing this back would be a good convo - I realize many of these runtimes will be edge environments where there is no FS, but having a single API for reading/writing files across all runtimes would still be useful.

Right now, if I'm writing a script that will generate files, save an image that is returned from an API or any other FS activity, I need to decide which runtime I'm using since the FS apis aren't all the same. Right now the Node APIs are almost becoming the standard in bun/deno if you want it to work cross-runtime.

Browser + worker compat could be handy as well, though admittedly not something I've wanted or needed yet.

So, would it make sense to implement these APIs across all runtimes?

[JakeChampion]

Right now the Node APIs are almost becoming the standard in bun/deno if you want it to work cross-runtime.

I would vote to not bring in Node APIs, they are not in the Web Platform APIs, which is what the WinterCG has stated as the goal.

The members of the group want to provide a space to better coordinate between browser vendors and other implementors on how Web Platform APIs can be best implemented and used outside of browsers.
Source: https://wintercg.org/faq#what-are-we-trying-to-do

If file-system like APIs are wanted, we should be looking to adopt and/or provide feedback on the Web Platforms APIs which provide file-system access. I do think this shouldn't be a part of the Common Minimum API however, as filesystem access is likely something not all runtimes are going to offer

[wesbos]

Another vote for adding FS APIs. I keep seeing over and over runtime lock-in because of filesystem APIs. I get that not all runtimes support FS, but many build tools and CI scripts do require file system access.

The move right now is to just use node FS apis, as Deno and Bun support them, but wouldn't a standard be better?

[mk-pmb]

Runtimes that don't want to grant file system access can just pretend a failing file system, can't they? Would such a stub be easy to implement?