Use package dependencies

[streamich]

No description provided.

[github-actions]

🎉 This PR is included in version 4.9.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[G-Rath]

Awesome! how you'd feel though about inlining sonic-forest? it looks like we're just using printTree which is a single 15 line file, but the dependency is 300kb+

[streamich]

[..] but the dependency is 300kb+

@G-Rath Where do you see that? It should not be that big.

[streamich]

Oh, sonic-forest emits source maps, I guess that is one reason. I'll remove those. But even without the source maps it is sizeable.

I don't know, on one hand, 64Kb (without source maps) for a single function is too much. One the other hand, I don't want to copy-paste those functions all over the place.

I guess the win-win would be to publish printTree as a separate package. I'll put it in a separate package.

[streamich]

memfs is 404Kb, sonic-forest without source maps is 66Kb.

[G-Rath]

For context, this is the tree for v4.9.1:

❯ du -h --max-depth 2 node_modules | sort -rh
6.3M    node_modules
2.7M    node_modules/@jsonjoy.com
1.5M    node_modules/memfs/lib
1.5M    node_modules/memfs
1.3M    node_modules/@jsonjoy.com/json-pack
1.2M    node_modules/@jsonjoy.com/util
936K    node_modules/hyperdyperid
916K    node_modules/hyperdyperid/lib
728K    node_modules/thingies
368K    node_modules/sonic-forest
356K    node_modules/sonic-forest/lib
236K    node_modules/thingies/lib
236K    node_modules/thingies/es6
236K    node_modules/thingies/es2020
232K    node_modules/@jsonjoy.com/base64
128K    node_modules/tslib
16K     node_modules/tslib/modules
8.0K    node_modules/memfs/demo

and pov-wise I'm caring about this as a user of webpack-dev-server which depends on this package (and only the original "memfs" part) - that to me represents a huge portion of users (including myself) that use this library; I use memfs on a few projects for my test suite, but the bulk of things I work on are PHP and Rails applications where all the fs lifting is done in languages other than JavaScript.

That's why I originally inlinined jsonjoy as at the time it all added up to ~20mb.

---

I agree with the general principle of using packages to avoid duplication of code, but I think there's a threshold that has to be met and I would be surprised if this function meets that - even if it's used in a couple of places, we're talking about ~500 bytes for this particular function, and it's not been changed in years from what I can tell; do you really think it's worth you spending the time to make it a dedicated package right now? (keeping in mind too we can always do that later).

That's also why I've opened jsonjoy-com/util#2 because that's even less code.

I think my overall concern with these packages is that right now they're still a bit too broad especially for the "webpack-dev-server" user - personally I'd really like to see something like "memfs-core" or "memfs-lite" that contained the original vanilla memfs that folks like webpack-dev-server can use, and then all the other more advanced fs's live in somewhere like "memfs-full" or something. I'm happy to help with doing and managing this if you'd like.

[streamich]

[..] personally I'd really like to see something like "memfs-core" or "memfs-lite" that contained the original vanilla memfs that folks like webpack-dev-server can use, and then all the other more advanced fs's live in somewhere like "memfs-full" or something. I'm happy to help with doing and managing this if you'd like.

How do you imagine this, would it be some monorepo/workspace, or just two packages: (1) original memfs; (2) everything else?

[G-Rath]

I think I'd start by having just the two packages: memfs in its original form, and then another package/repository for everything else.

In the long-run a monorepo might make sense for the "everything else" but I think it really depends on how all that is expected to be used which I don't have a good sense of i.e. you could have fs-cas, fs-crud, fs-fsa, etc but I don't know if there's a case for using one without the other, and they also might have more complex interdependencies than what memfs has.

[streamich]

OK, sounds like a plan:

• tree-dump package contains the printTree function, already published.
• fs-zoo will have all the extras on top of canonical memfs, WIP.

[G-Rath]

Awesome, and love that name to boot! Feel free to add me as a contributor if you'd like help with maintaining any of the new packages.

Do you want to aim to remove the fs's from memfs in v5? So long as we retain Node v18 support, then that should allow folks like webpack-dev-server to upgrade to v5 without requiring a breaking change themselves.