Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch from browserfs to zenfs #14125

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

robertjndw
Copy link

What it does

This PR builds on top of the work that was done in PR #12853.
As browserfs was deprecated in March 24 (see original repo), it is beneficial to switch to the actively maintained fork zenfs (see here).

In addition to the active maintenance, the fork also introduces some new features and an improved API (e.g. promise based instead of callback). The new features will simplify the implementation of the missing parts in the BrowserFSFileSystemProvider

How to test

Build and run the 'browser-only' Theia example.

Similarly to the previously mentioned PR #12853.

Follow-ups

The unimplemented methods of the old PR still exist in this one and will be implemented in a future PR.

Review checklist

Reminder for reviewers

Copy link
Member

@sdirix sdirix left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the work! I ran it locally and ZenFS worked as expected for me.

I have some minor comments, please have a look

Comment on lines 21 to 29

export const BrowserFSInitialization = Symbol('BrowserFSInitialization');
export interface BrowserFSInitialization {
createMountableFileSystem(): Promise<MountableFileSystem>
initializeFS: (fs: FSModule, provider: BrowserFSFileSystemProvider) => Promise<void>;
createMountableFileSystem(): Promise<void>
initializeFS: (provider: BrowserFSFileSystemProvider) => Promise<void>;
}

@injectable()
export class DefaultBrowserFSInitialization implements BrowserFSInitialization {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should rename these symbols, interfaces, classes etc.

Comment on lines +13 to +14
"@zenfs/core": "^0.16.4",
"@zenfs/dom": "^0.2.14",
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change (and the suggested renames) need to be listed as breaking changes in the Changelog


@injectable()
export class ExampleBrowserFSInitialization extends DefaultBrowserFSInitialization {

@inject(EncodingService)
protected encodingService: EncodingService;

override async initializeFS(fs: FSModule, provider: BrowserFSFileSystemProvider): Promise<void> {
override async initializeFS(provider: BrowserFSFileSystemProvider): Promise<void> {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not look into zenfs. Is this the expected usage? Seems weird to get rid of the filesystem as a parameter as it seems to lose flexibility.

Copy link

@james-pre james-pre Sep 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sdirix,

Is this the expected usage?

Yes, using the fs import/export is correct.

Seems weird to get rid of the filesystem as a parameter as it seems to lose flexibility.

Not using instances for the emulation layer has simplified the internal API a lot since ZenFS doesn't need to worry about handling said instances. ZenFS' configure allows a lot of flexibility.

Additionally, if you'd like to continue using dependency injection, you can still do so. For example:

import type { fs } from '@zenfs/core';

export type FSModule = typeof fs;

export class ExampleFSInitialization {
	// ...
	initializeFS(fs: FSModule) // ...
	// ...
}

However, I would not recommend this since it adds unneeded complexity. It may be easier to allow the user to pass in the configuration object instead.

@sdirix
Copy link
Member

sdirix commented Sep 4, 2024

I had a closer look at @zenfs/core. I think it should be discussed whether we really want to switch to this framework or rather check whether we should integrate a more popular alternative down the line.

@msujew msujew mentioned this pull request Sep 20, 2024
@james-pre
Copy link

james-pre commented Sep 29, 2024

@sdirix,

I don't mean to pressure the team, but ZenFS is now more popular than BrowserFS (due to @dsnp/parquetjs, which has ~36000 weekly downloads), with ~8800 weekly downloads to BrowserFS' ~5900 at the time of writing. Additionally, @zenfs/core 1.0.0 will be released in a couple of days, so the API will be guaranteed to be stable.

@robertjndw You may want to try 1.0.0 Release Candidate 0 (1.0.0-rc.0) over the next few days, and update the version of @zenfs/core to 1.0.0 once it comes out. I also plan on updating the other packages (e.g. @zenfs/dom) so the referenced core version is ^1.0.0.

@sdirix
Copy link
Member

sdirix commented Oct 1, 2024

@james-pre Thank you for your work on zenfs.

We are currently considering several options, including a switch to zenfs or leveraging OPFS directly. We'll keep you informed as we finalize the decision.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Waiting on reviewers
Development

Successfully merging this pull request may close these issues.

3 participants