Switch to use browser-fs-access npm module directly

[tomayac]

This PR switches logseq to use the browser-fs-access npm module directly. It was using code from the project already, and the mentioned babel transform issues have (hopefully) been fixed.

[CLAassistant]

All committers have signed the CLA.

[logseq-cldwalker]

@tomayac Hi. Thanks for the interest. Have you been able to QA what this is being used for? If we decide to go ahead with this, we'll probably ask for some QA since we don't have tests here

@tiensonqin Thoughts on if this worth doing at this time? I see this is related to code introduced back in #724

[tomayac]

This is barely a housekeeping PR that doesn’t introduce new functionality, but simply uses the browser-fs-access library code directly as a dependency; the same code which #724 extracted from the library manually (as per the comments in the logseq source code and the PR), since the build tooling used back then wasn’t compatible with logseq’s, but which after updating works fine now.

[Bad3r]

@tomayac Hi. Thanks for the interest. Have you been able to QA what this is being used for? If we decide to go ahead with this, we'll probably ask for some QA since we don't have tests here

@tiensonqin Thoughts on if this worth doing at this time? I see this is related to code introduced back in #724

This is what the web app uses to access the local filesystem.

https://developer.mozilla.org/en-US/docs/Web/API/File_System_Access_API

I will build the web app from this branch and release it to the testing channel.

I'll provide the link once it's done building.

[tomayac]

(FWIW, I successfully tested locally in the Web browser and in Electron.)

[Bad3r]

(FWIW, I successfully tested locally in the Web browser and in Electron.)

Thank you. Its always good to have an extra pair of 👀

Docker image is building: https://github.com/logseq/logseq/actions/runs/4227294573/jobs/7341620379

once done it will be available via the testing channel:
https://github.com/logseq/logseq/pkgs/container/logseq-webapp

[Bad3r]

Note
Non-blocking
Effacts the latest release as well

hmm something is wrong. I can't get the filesystem API to work.
Tested in a clean testing env:

• Windows version 10.0.19044 Build 19044
• Chrome: Version 110.0.5481.104 (Official Build) (64-bit)
• Edge: Version 110.0.1587.50 (Official build) (64-bit)

Not sure if this issue was introduced by this PR. I remember someone reporting a similar issue on the forum or discord. More testing is needed.

Anyone is able to test the docker image on MacOS?

docker run -d --rm -p 3001:80 ghcr.io/logseq/logseq-webapp:testing

then navigate to http://0.0.0.0:3001 to view the webapp.

CC: @andelf, @cnrpman

[Bad3r]

Tested and the issue also affects the latest release 🤦‍♂️
That means the issue is non-blocking for this PR.
Not sure what broke it.

docker run -d --rm -p 3001:80 ghcr.io/logseq/logseq-webapp:latest

[tomayac]

Glad to learn that the breakage is unrelated to my PR, but curious to understand what caused it in the latest release. I’ll have a look.

[andelf]

src/main/frontend/fs/nfs.cljs is not touched.
So some file actions will fail.

[andelf]

@Bad3r To test the filesystem API, use either localhost or https access.

[andelf]

Many thanks. I'll refactor this in #8792.

UPDATE: won't introduce this for now.

[andelf]

After looking into the implementation, this should be a buggy design decision.
The directoryHandle only binds to the containing directory, not the top directory.

[tomayac]

Good this got caught.