One monolithic repo

[streamich]

Vendor necessary code from upstream dependencies. Consolidate all code in one memfs repo and discontinue auxiliary packages:

• [ ] unionfs
• [ ] fs-monkey
• [ ] linkfs
• [ ] spyfs

[G-Rath]

Is there a particular advantage you think this will give? note that semantic release doesn't support doing different versions for packages (https://github.com/semantic-release/semantic-release/issues/193) and I don't think it makes sense for all these packages to go through the same versions

[streamich]

I was thinking, there would be just one package (memfs), at least initially, which would now have code from those other packages, the other packages could be discontinued. WDYT?

The advantage is faster development cycle, less management.

[G-Rath]

Right, but that could make it harder to do some changes and new majors (e.g. if we want do a breaking change to the unionfs interface, without needing to change the API of the rest of the package), plus mean you're pulling in more code even if you never use the features (I've never used linkfs or spyfs personally).

I'm not saying we definitely shouldn't do it, but it feels like we're just trading one set of problems for another set of similar size rather than actually eliminating the total 😅

I tend to use memfs primarily, and then sometimes use unionfs but have never needed linkfs or spyfs - so for me having them in their own packages so I can choose to bring their feature set in is nice from a less-code POV.

[streamich]

You are right. My original impetus was to remove memfs dependency on fs-monkey—it used to import fs-monkey lists, but now the lists are part of memfs. I guess fs-monkey "vendoring" is sort-of done, then.

I guess the goal is not to take the code as-is from those packages and simply plunk it into memfs. But instead improve memfs such that those packages would not be necessary.

For example, the most "necessary" part from fs-monkey was that method list. With regards to unionfs, maybe new API in memfs could provided the needed functionality, like:

const { vol } = memfs();

vol.addReadOnlyLayerAtPath('/real-fs', require('fs'));

spyfs could be replaced by some build-in event system. The EventTarget API is now available, both, in browser and Node:

vol.addEventListener('read', event => {
  if (event.filename === '/my-file') {
    event.preventDefault();
    // ...
  }
});

Essentially, memfs features would make those packages absolete.

[MichaelJCole]

For the size of the code base, I'm not worried about including extra modules. I'm more interested in having integrated docs, types, issues, and tests for using them together. As a user, I think this is a good idea.