Implement Native File System API

[askbeka]

The proposal for native file system is out.
Where does deno stand?

[ry]

It looks good. I would take patches to support it on top of our own posix API.

[kitsonk]

While it is great to align to, I would hold off a little bit, the draft is less than 24 hours old and we aren't in a position at the moment to influence the standard, so I would say we would want to see one of the other browsers vendors with a reference implementation before we really make an attempt, as first implementation almost always causes churn.

The platform status for the feature indicates that none of the browsers vendors have a plan to implement yet, though obviously it is being sponsored out of Chromium and they have an active bug and it is allegedly targeted for 77, but I don't really believe that based on the status on the issue, though who knows.

[askbeka]

@kitsonk agree with you.

Would be nice to introduce approach to handle this sort of new specs. Even though deno wants to be browser compatible which is a great goal, that's why I like it, but sometimes they might conflict with existing implementations.

An approach @ry and @kitsonk have proposed looks ideal to me, reuse existing primitives for implementations and wait for one of the browsers go live with it.

In meantime we can also start from a implementation in a separate "module" and when it is more or less stable integrate into the core or std.

P.S. what do you think about https://github.com/tc39/proposal-javascript-standard-library

[kitsonk]

Regarding standard-library, I think we have talked about it before. My personal opinion is that it will be a long and fraught road to be able to do that. There is such a wide opinion on what should be in a standard library, and that would just be within TC39. I have seen the TC39 process work well over the past several years and would absolutely want to align to a proposal as it matures to stage 2 and 3. I suspect it will be too big to swallow as one and we will see more built in modules agreed (though built in modules are going to be a bit of a battle ground too, I suspect).

As far as a process, to take on new standards, I think we need to mature more, get a bit older, before we can really be more regimented in things like that. My opinion is that it will largely need to be "scratch your own itch" under the guidance of Ry and Bert for a while, with some good debate thrown in now and again.

[ry]

+1 for holding off

Ideally we will soon be able to push most of the JS code in core out into deno_std (and perhaps with the DLL patch @afinch7 is working on, we may be able to push most rust op code out there too). It's less dangerous to iterate in deno_std since it doesn't introduce complexity into the runtime itself.

[josephrocca]

@kitsonk Chrome (v86) and Edge (v84) have rolled out the Native Filesystem API now, so perhaps this can now be more seriously considered?

[kitsonk]

Yes. Now that there are other implementations, it is certainly worth implementing.

[caspervonb]

It's still just an origin trial isn't it? Issue tracker looks to have about the same unresolved issues.
Also Edge being Chrome I don't really consider those separate browsers, personally I think it seems like it may still be too early.
It would at the very least have to be unstable.

[kitsonk]

@caspervonb it is released in Chrome 86 (which as of this writing is the next release). The origin trial is complete. That is good enough for me to start down the path of implementing.

[Seanmclem]

The feature is pretty stable still. It does seem pretty tightly coupled to the browser though. For instance, you can't even use it in codesanbox, because it doesn't like not being in a dedicated browser session or something.
Re: Filesystem access API

[josephrocca]

it doesn't like not being in a dedicated browser session or something

I'm guessing this is just due to iframe sandboxing or headers.

Here's a simple example of using this API in the browser (more examples here):

let dir = await globalThis.showDirectoryPicker();
let file = await dir.getFileHandle("hello.jpg", { create: true });
await blobToSave.stream().pipeTo(await file.createWritable());

And this triggers a directory picker (like a normal save-as dialogue) and then two permission prompts (one for reading, and one for writing). For UX/UI reference, here are the dialogues after selecting a directory called "inpaint" in the directory picker:

I guess this would work similar to prompt() in that it interactively asks for input? Not sure if there's a common UX/UI for this, but I like ncdu's UI - up/down to move between files and folders in a directory, and right/left to move into and out of a folder.

It would be nice to be able to use feature without user interaction, and that would of course be possible from a technical standpoint if the script was run with the right --allow-read/--allow-write permissions. But the API of course doesn't give the ability to request access to a directory that is relative to the location of the script, because the script doesn't have a local file-system location when it's running on the web.

You can write await globalThis.showDirectoryPicker({startIn:startingDir}), but startingDir must either be a directory handle or one of a few well-known directory names (like pictures, documents, etc. - see here). So this is not ideal.

Seems like this will require some careful thought to get this right - perhaps best to only implement the interactive version for now. I wonder if it would make sense to just expose the parameters of --allow-read=... and --allow-write=... as file handles in a Deno API? And if they allow read and write to whole filesystem, then just give a handle to the root of the filesystem? I think something along those lines might make sense.

@kitsonk This API has had a name change to "File System Access" - might be worth changing the issue name to make this issue easier to find.

[jimmywarting]

Hi, I have develop a pluggable adapter/polyfill that follows the file system access specification. Meaning: you can hookup any storage you want with it. I just uploaded a adapter for Deno

if you would like to try it out then you can import this typescript friendly (jsDoc:ed) ESM module in browser, deno, or node

import {
  getOriginPrivateDirectory as getDirectory
} from 'https://cdn.jsdelivr.net/gh/jimmywarting/native-file-system-adapter/src/es6.js'

cdn = 'https://cdn.jsdelivr.net/gh/jimmywarting/native-file-system-adapter/src/'
fileSystemDirectoryHandle = await getDirectory(import(cdn + 'adapters/memory.js'))
fileSystemDirectoryHandle = await getDirectory(import(cdn + 'adapters/deno.js'), './starting_directory')

fileHandle = await fileSystemDirectoryHandle.getFileHandle('./readme.md')
file = await fileHandle.getFile()
text = await file.text()

[lucacasonato]

Closing in favor of #11018. It has more up to date details and API specification.