MAmachiaweliczny·Jan 13, 2026
Yeah, seems like this could be achieved by using https://github.com/streamich/memfs/blob/master/docs/snapshot...
Weird they don't use it - might backfire hard
In Cowork: Claude Code for the rest of your workstreamich
memfs
TypeScript2022–2026
streamich / memfs
memfs
Node.js "fs" and browser "File System API" adapters and in-memory implementations 👍
3Distinct people
3Mentions
0Explicit recommenders
2.1KGitHub stars
What to know before exploring
What it is
Node.js "fs" and browser "File System API" adapters and in-memory implementations 👍
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year3 dated mentions
Observed mentions: 2022-10-10 01:17:26 UTC to 2026-01-13 09:14:03 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
3 sourcesI am using the Python ecosystem (with full support for dynamic loading of C extension modules) as an initial motivating project. Also, the Python test suite is extremely useful to root out problems. I certainly hope that this can provide a more complete alternative to Emscripten to the community eventually. That said, Emscripten is huge, and the problems involved in creating a more maintainable modular WASM build tool are subtle. For example, when implementing a custom module loader for Python-wasm last week, I discovered several bugs in the memfs and unionfs Javascript libraries (https://github.com/streamich/memfs/pulls?q=is%3Apr+author%3A... and https://github.com/streamich/unionfs/pulls?q=is%3Apr+author%...). I had to learn the code sufficiently to fix all these bugs, submit PR's, etc. Emscripten has its own analogue of memfs, w
Read the rest
hich is optimized specifically for WebAssembly in the browser, where memfs is a more general widely used library (with 10M+ downloads/week).
CoWasm has no support for asyncify. Where I've run into setjmp/longjmp so far, I've been rewriting the code instead. E.g., the dash shell uses setjmp/longjmp, and I'm rewriting that to use return error codes instead (see, e.g., https://github.com/sagemathinc/dash/commit/7117e1f6496728af0...).
> how would I go about porting a simple C->WASM w/ Typescript library project to CoWasm?
That's a great question, which I'm not sure how to quickly answer, so I've created a discussion item here https://github.com/sagemathinc/cowasm/discussions/40
I did a massive refactor of the codebase during the last month, and it makes doing what you want much easier. However, it will help a lot once there are some good examples. I'm probably boing to individually package some of the things I've ported for CoWasm as standalone examples.
In any case, CoWasm is extremely open source (BSD 3-clause), and I strongly encourage anybody who is interested to grab a copy, build it, poke around, make a PR, etc.
Score another point for memfs, the in-memory node.js fe impl (which if Im reading this right underpins your wasi fs impl). https://github.com/streamich/memfs
Edit: apologies... your reply says you have you own impl! Damn, awesome! Apologies, I'd seen memfs in a dependencies here: https://github.com/taybenlor/runno/blob/main/packages/runtim...
WHATWG recently took up File System Access spec as their FS spec. It both looks semi promising, but they seem to only care about & are only building specs for specifically emscripten wasm users. Only sync apis, only usable from dedicated workers... there's some hopes for more latter but feels super weird to see the web finally get fs access & have it be fast... but for it to be extremely odd shaped hand tailored to a very narrow class of use.
https://fs.spec.whatwg.org/
In Show HN: I built a WASI playground for running CLI binaries in the browser