Why not join isomorphic-git?

[iliakan]

Why did you choose not contribute to isomorphic git, but fork/rewrite to your own library instead?

Also, are the any differences compared to isomorphic git, except this one being TypeScript?
I see, you wrote FsClient for File System Access, anything else?

[alex-titarenko]

Hi @iliakan

If you go to Isomorphic-Git Gitter and scroll a little bit, you can actually find my post, related to why I did this. It's actually useful to reiterate here.

For sure TypeScript is not a benefit to end users by itself. But should be definitely for the developers who would like to contribute or just for someone who wants to understand how Git works. While converting code from JavaScript to TypeScript I found numerous mistakes and misalignments with the documentation. In this project, the documentation is auto-generated from TypeScript types and it's a more accurate representation of the code which I would call a benefit for end users. I saw more than one PR in isomorphic-git related to API documentation changes which should not be a problem here.

There are some other changes as well:
The approach how to work with CORS is changed. Rather than be a property of git commands it's a feature of WebHttpClient. It gives more flexibility than just corsProxy property. For example: if you want to use the library in a hybrid application you may want to do CORS proxy on a native client instead of a server and one of the ways to achieve this is to use custom protocols. Using corsProxy parameter will fail in this case with the error of an unknown protocol, but will work perfectly fine with a new approach. This I can call this a benefit for end users.

Also, I included 3 FsClients in the library which works in the browser. Even so, the original lightning-fs is fast it has a major drawback because it uses debouncing and you may get into a broken state when the Git command is interrupted in the middle. I learned that the hard way while developing https://noteshub.app/ and because of that project git-essentials was born. The lightning-fs still have some benefits since it supports more features than my implementations, but it was not usable in my case.

There are some small changes here and there and honestly, I can't recall all of them. One of the is the approach how to dealing with merge conflicts. I implemented that feature before it was introduced in isomorphic-git but it has more flexibility and can cover more scenarios like when there is a conflict with binary files.

I changed the way how unit-testing is done even so it's debatable if it's better or not but definitely has some benefits. Instead of relying on a local Git server and file system, it uses JSON fixture files (which could be easily auto-generated) as results unit tests are faster and execution is more predictable. Also, unit-tests are now discoverable with VS Code. You can use Jest VSCode extension to run/explore and debug tests with ease. Also for whatever reason, I can't just run isomorphic-git unit tests on Windows without any magic. With git-essentials, there is no problem here since it's done more simpler under to hood. I use MacBook for development but tried on Windows just for validation.

All of the dependencies are up to date. I just cloned the latest isomorphic-git and run npm install and it showed me 105 vulnerabilities. In git-essentials I have fewer dependencies and dev-dependecies and they are more up to date, in my case I have 0 vulnerabilities.

I'm developing https://about.noteshub.app and it was the primary driver for this new project. I tried to contribute to isomorphic-git back in 2020 and even have one PR merged into isomorphic-git. Then I tried to do more changes but back then was no active maintenance for the original project and my PR was overlooked. At that time I created a fork from isomorphic-git and started making my changes there where I had some bug fixes. Then I needed more changes and for me, it was hard to make a reliable contribution using JavaScript so then the idea was born to create a smaller version of essential commands from isomorphic git but written in TypeScript that would be easier for me to maintain and to be used for NoteHub.

[iliakan]

Thank you, @alex-titarenko!

Surely I'd wish the improvements be all targeted into a single project, rather than split between two.

[alex-titarenko]

I think wasm-git library will not work for me because of WebClient. I don't see a way to provide a custom implementation for fetch API. In the pure browser, you usually use CORS-proxy server as a middleman to make Git work on the client, which I'm currently doing to access GitHub. But in iOS/macOS/Android/Windows WebViews I have a thin native bridge layer to workaround this limitation and to have direct calls to GitHub without an external CORS server.

[iliakan]

Did you see this file? https://github.com/petersalomonsen/wasm-git/blob/master/emscriptenbuild/post.js#L27

It basically provides the HTTP implementation to use, and it looks like there can be anything.

And CORS can be used there as well.

So it appears, HTTP-issues were solved by the wasm-git author ;)

[alex-titarenko]

@iliakan thank you for pointing this out, I did not see it. It will have some small performance drop since it will need to copy data from JavaScript into WebAssembly.

Also, I found this: https://emscripten.org/docs/api_reference/Filesystem-API.html#new-file-system-wasmfs
And they have a link to the design doc https://docs.google.com/document/d/1-ZxybGvz0nCqygUDuWxCcCBhCebev3EbUSYoSOlc49Q/edit

So basically FS access as of right now (based on my understanding by reading the page above) is not very performant because the current implementation is written in JavaScript and has the same problems with passing data back from JavaScript to WebAssembly (the same as web requests).
But with the new WasmFS, they are going to solve this problem, the work is in progress and the design document was last updated in 2021, so not sure when it will be production ready.
The interesting part of the design document is:

Support Asynchronous (Main Thread) / Synchronous (Worker Threads) Backends: This includes OPFS.

OPFS - Origin Private File System, which is basically a sub-part of File System Access API, and basically this is what I need. It is supported by Chromium browsers and WebKit.

Until they start supporting WasmFS, it does not make sense for me to try to switch, but I'll monitor the progress on that project, thank you for your reference.

[alex-titarenko]

@iliakan can you accept my request on LinkedIn? I want to be able to message you privately if that is ok.

[iliakan]

WasmFS has a lot in TODO list yet, so it's not an option.

If you need just a few pieces of git-related functionality, then taking the whole libgit2 looks an overkill indeed.

P.S. I rarely visit linkedin, so yeah, requests are often overlooked, sorry. I accepted it now.