Fix package import

[zardoy]

Hi! I'm not sure what about others but in my case TS doesn't see any types when i try to import anything from @zenfs/core.

It seems "typesVersions" is the reason. Why do you need to specify this field at all? with * it won't do much... So it worked only when I changed "./dist/*" in typesVersions to "./*"

Also, just curious is this "fork" going to replace the original browserfs module? Will you continue the development of BrowserFS, or should I stop using it? I just can't find much info on the name change reasons

EDIT: btw also noticed the zip package is outdated and using non-existing imports

[james-pre]

Thank you so much for continuing to help ZenFS. I really appreciate it.

It seems "typesVersions" is the reason. Why do you need to specify this field at all? with * it won't do much... So it worked only when I changed "./dist/*" in typesVersions to "./*"

For typesVersions, I can't remember the exact reasons. If the types field in package.json is all that is needed for proper types, typesVersions can be removed.

Also, just curious is this "fork" going to replace the original browserfs module? Will you continue the development of BrowserFS, or should I stop using it? I just can't find much info on the name change reasons

Please read the notice in the readme: https://github.com/jvilk/BrowserFS

btw also noticed the zip package is outdated and using non-existing imports

Thanks I will update it in a minute. The core API should be stable now so hopefully these updates won't be needed as much in the future. I will update zip ASAP.

[zardoy]

For typesVersions, I can't remember the exact reasons. If the types field in package.json is all that is needed for proper types, typesVersions can be removed.

Yes it should be removed in your case. And "types" should be a path to file eg ./dist/index.d.ts to avoid auto-import issues in certain IDEs 👍

[james-pre]

I would like to answer your questions fully since I don't think the message I linked to explains everything:

Also, just curious is this "fork" going to replace the original browserfs module?

That depends. While I would like to see BrowserFS superseded by ZenFS, I don't think I alone can determine whether ZenFS will officially be the replacement. @emeryberger is currently administering to BrowserFS, so you can reach out to him if you would like to support ZenFS becoming the official replacement. I am a former maintainer of BrowserFS, not its owner, so I feel some of these decisions are not up to me.

Will you continue the development of BrowserFS, or should I stop using it?

I don't plan on making any changes to BrowserFS, mainly because I have no way to distribute those changes. I still do not have access to the browserfs NPM package and don't expect to gain access since John Vilk is very busy. I would recommend you no longer use it since the NPM package may not get updated anymore. I do not have the permissions to deprecate the browserfs NPM package, so future users will not know about its deprecation unless they visit the GitHub repository.

I just can't find much info on the name change reasons

I feel like the notice explains this well— ZenFS became something significantly different from BrowserFS, to the point it was a separate project. Others questioned whether the new organization was even legitimately using the name, which is another reason I felt a name change was needed despite it being offical.

- JP

[james-pre]

@zardoy,

I've hopefully fixed the types in v0.9.3

I updated core in zip v0.1.5

Please tell me if these releases fix your issues.

[zardoy]

I've hopefully fixed the types in v0.9.3

Yes, you're a truly awesome maintainer, thank you! Now only need to backport these changes to zip and dom packages.

Also, since you publish src/ folder (and that's awesome) consider enabling sourcemap option in tsconfig so debugger shows source files when debugging.

Also, I noticed I'm getting a type error when I try to use either zip or dom FS in configure:

 await config({
    '/data': {
        backend: WebAccess,
        handle: dir, // ts error: Object literal may only specify known properties
    }
})

[james-pre]

Now only need to backport these changes to zip and dom packages.

Since 0.9.3 does not change any code, it should be possible to npm i @zenfs/core@latest to update the package. The various package (dom, zip, etc.) use peerDependencies so the user can choose which core version to use (provided that it is compatible).

consider enabling sourcemap option in tsconfig so debugger shows source files when debugging.

I didn't know about sourcemap in tsconfig, I'll make sure to do that.

Also, I noticed I'm getting a type error when I try to use either zip or dom FS in configure

I also have this issue, and have been getting around it by casting to BackendConfiguration, like this:

await config({
    '/data': <BackendConfiguration>{
        backend: WebAccess,
        handle: dir,
    }
})

Which should not be needed.

[zardoy]

(dom, zip, etc.) use peerDependencies so the user can choose which core version to use (provided that it is compatible).

But as far as I could see you only fixed the types (in package.json) of the core package, but not zip or dom.

[james-pre]

Sorry, I thought you meant to update zip, dom, etc. to the latest core. You mean removing typesVersion in them as well? I'll get to that tomorrow.

[james-pre]

@zardoy All of the packages have been updated. typesVersion was removed, types fixed, and src added to the package.

Does that resolve the issue?

[zardoy]

Yes, all good, would be awesome if I also didn't need to cast it to BackendConfiguration, but it's already good enough 👍

[james-pre]

Yes, that is why I made #48