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

feat(fslib): path buffer and file url support #1584

Closed
wants to merge 17 commits into from

Conversation

paul-soporan
Copy link
Member

@paul-soporan paul-soporan commented Jul 13, 2020

What's the problem this PR addresses?

FakeFS doesn't currently support Path Buffers and File URLs, unlike Node's built-in fs.

Fixes #899, fixes #1818.

How did you fix it?

I added support for Path Buffers and File URLs. I made it type-safe by adding specific Portable / Native variants of Path Buffers and File URLs. I also exposed the converters onto PathUtils. I also added tests.

Checklist

  • I have set the packages that need to be released for my changes to be effective.
  • I have verified that all automated PR checks pass.

@paul-soporan paul-soporan requested a review from arcanis as a code owner July 13, 2020 20:04
@paul-soporan paul-soporan force-pushed the paul/feat/fslib/buffer-and-url-support branch from d155791 to d53018e Compare July 15, 2020 17:05
Comment on lines +14 to 20
protected mapFromBase(path: PathLike<PortablePath>) {
return npath.fromPortablePath(ppath.fromPathLike(path));
}

protected mapToBase(path: NativePath) {
return npath.toPortablePath(path);
protected mapToBase(path: PathLike<NativePath>) {
return npath.toPortablePath(npath.fromPathLike(path));
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Btw, shouldn't we return the same type of PathLike as the one we receive? As we saw, the result of Buffer.from(Buffer.from([0xca, 0xc5, 0x0e]).toString('binary'), 'binary') is correct while the result of Buffer.from(Buffer.from([0xca, 0xc5, 0x0e]).toString('binary')) isn't. That means that the string representation would break if definitely turned into a string, right?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would also be safer to include tests that use [0xca, 0xc5, 0x0e] to be sure that we handle this tricky case properly.

@paul-soporan paul-soporan marked this pull request as draft July 26, 2020 19:28
@alubbe
Copy link
Contributor

alubbe commented Dec 10, 2020

just came across this PR, wouldn't this fix #2229?
What's the status here, is there anything we can do to help push this across the finish line? Pinging @sohai

@merceyz
Copy link
Member

merceyz commented Dec 10, 2020

Getting the buffer part to work is a bit of a nightmare, would be possible to split this to get URL support first which seems to be working

@paul-soporan
Copy link
Member Author

I'll rebase (this will be fun) and remove the buffer part until I manage to get it working. The last time I tested it, the URL part worked without any catches.

@arcanis arcanis closed this in #2291 Jan 2, 2021
@merceyz merceyz deleted the paul/feat/fslib/buffer-and-url-support branch March 15, 2022 15:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[Bug] fs functions that use buffer encoding fail [Bug] URL instances are not supported by the FS layer
5 participants