`memfs` no longer exports `Volume` — breaking builds that rely on named exports

[MarketingPip]

Problem

When resolving memfs@^4.20.0 (via package.json or CDN like esm.sh), the module no longer exports Volume as a named export. This causes builds or runtime scripts to fail with:

Uncaught SyntaxError: The requested module '/memfs@^4.20.0' does not provide an export named 'Volume'

Root Cause

The version resolver is pulling in memfs@^4.20.0, but starting in a recent update, Volume is no longer available as a named export — possibly moved or hidden behind a default export.

Impact

• Scripts that rely on this previously valid syntax now break:

import { Volume } from 'memfs'; // ❌ fails

• This issue occurs when building or running environments that depend on a shared package.json (e.g. workspaces, CDN builds).

---

Expected

One of the following should happen:

• Either Volume is restored as a named export (as it was in ≤4.9.3), or
• The documentation/update log clearly reflects the breaking change, and guidance is provided to access Volume correctly (e.g. via default export or subpath).

[MarketingPip]

@sebastianwessel - As mentioned earlier, this package is broken, you can either:

• Downgrade to the previous working version of memfs:

  "memfs": "4.20.0"

• Or try the newer version - although at the moment, it seems that all current releases are broken.

(Off-topic, just for my understanding):
When I fork this repo, I notice I’m forced to use the CDN URL with the full path, e.g.

https://esm.sh/gh/My_Username/_quickjs/src/index

instead of the direct build:

https://esm.sh/gh/My_Username/_quickjs

Otherwise, I get the error:

could not resolve build entry

Could you explain why that happens? I’m trying to understand how esm.sh determines the correct build entry for GitHub-based packages. As I seem to be confused.

I would submit a PR for this, but being I can't even figure out esm.sh right now - I will pass lol!