Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

One monolithic repo #956

Open
4 tasks
streamich opened this issue Oct 7, 2023 · 5 comments
Open
4 tasks

One monolithic repo #956

streamich opened this issue Oct 7, 2023 · 5 comments
Labels

Comments

@streamich
Copy link
Owner

streamich commented Oct 7, 2023

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

@G-Rath
Copy link
Collaborator

G-Rath commented Oct 7, 2023

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

@streamich
Copy link
Owner Author

streamich commented Oct 7, 2023

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
Copy link
Collaborator

G-Rath commented Oct 7, 2023

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
Copy link
Owner Author

streamich commented Oct 7, 2023

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
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants