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

Add Node.js 12 support to react-fs #20541

Closed
wants to merge 5 commits into from

Conversation

MylesBorins
Copy link

Summary

With a slight modification to an import statement in react-fs it should
now support Node.js 12.

Test Plan

Start testing this module in Node.js 12

With a slight modification to an import statement in react-fs it should
now support Node.js 12.
@facebook-github-bot
Copy link

Hi @MylesBorins!

Thank you for your pull request and welcome to our community. We require contributors to sign our Contributor License Agreement, and we don't seem to have you on file.

In order for us to review and merge your code, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

If you have received this in error or have any questions, please contact us at cla@fb.com. Thanks!

@MylesBorins
Copy link
Author

I've now signed the CLA

@codesandbox-ci
Copy link

codesandbox-ci bot commented Jan 4, 2021

This pull request is automatically built and testable in CodeSandbox.

To see build info of the built libraries, click here or the icon next to each commit SHA.

Latest deployment of this branch, based on commit f49efc8:

Sandbox Source
React Configuration

@facebook-github-bot
Copy link

Thank you for signing our Contributor License Agreement. We can now accept your code for this (and any) Facebook open source project. Thanks!

@MylesBorins
Copy link
Author

I got the yarn build script working... the flow script needs to be updated and it isn't clear if this is something that is generated or hand rolled. Would rather not waste time if there is a script to create it 😇

@sizebot
Copy link

sizebot commented Jan 4, 2021

No significant bundle size changes to report.

Size changes (stable)

Generated by 🚫 dangerJS against f49efc8

@sizebot
Copy link

sizebot commented Jan 4, 2021

No significant bundle size changes to report.

Size changes (experimental)

Generated by 🚫 dangerJS against f49efc8

@MylesBorins
Copy link
Author

ok... I managed to get flow working (I think). I've never used flow before... so I had to guess at what was going on... please feel free to let me know if I did something wrong or if there is a better way to do this.

originally there was an additional flow definition added for fs/promises, I think to overload the defaults for promises since it seems like you are using a slightly different interface. This worked nicely before, as you were only over riding the built in definitions for fs/promises.

To get the flow definitions working I had to manually recreate the fs flow definitions (using the existing definitions in the repo as well as the included flow definitions for the interfaces of fs being used).

My gut is that the way I did it is more verbose than needed... but at least the flow definitions work 🎉

@gaearon
Copy link
Collaborator

gaearon commented Jan 7, 2021

Thanks for the PR! Do you know if the demo fully runs on Node 12 after this? I'm not sure how useful this is in practice since these packages won't be production-ready for a while, and 14 is LTS anyway.

@MylesBorins
Copy link
Author

hey @gaearon

I beleive that the demo does fully run on Node 12 after this change (and the one I sent to the demo)... although to be honest I didn't test it out extensively.

): Promise<mixed>;
stat(path: string, options?: ?{bigint?: boolean}): Promise<mixed>;
}
declare var promises: FSPromise;
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think you can put the type here inline without a class?

declare var promises: {
  // ...
}

Copy link
Author

Choose a reason for hiding this comment

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

This pattern was copied directly from the default type definitions

Copy link
Author

Choose a reason for hiding this comment

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

declare var readdir: (
path: string,
declare module 'fs' {
declare function existsSync(path: string): boolean;
Copy link
Collaborator

Choose a reason for hiding this comment

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

Kind of unfortunate that we're not relying on built-in definitions here. Maybe we can just get rid of this when we update Flow and get Promises from upstream.

Copy link
Author

Choose a reason for hiding this comment

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

So there are built in definitions that could be used but there is no promises definition for fs.promises.lstat, fs.promises.stat does not define an option, and the default fs.promises.realpath is ambiguous.

If there is an easy way to overload specific entries with flow? I couldn't figure out how to do that, but if we could overload just those three functions we could avoid the rest of the noise

@MylesBorins
Copy link
Author

@gaearon there are only 5 calls to fs promise APIs that were causing issues with the built in flow definitions. I've pushed f49efc8 which ignores types for those 5 calls so we can remove all the custom type information related to fs / promises and rely entirely on the built-in types elsewhere. Unsure if this approach is preferable, feel free to drop the commit and force push if you don't like the approach.

@stale
Copy link

stale bot commented Jun 11, 2021

This pull request has been automatically marked as stale. If this pull request is still relevant, please leave any comment (for example, "bump"), and we'll keep it open. We are sorry that we haven't been able to prioritize reviewing it yet. Your contribution is very much appreciated.

@stale stale bot added the Resolution: Stale Automatically closed due to inactivity label Jun 11, 2021
@gaearon
Copy link
Collaborator

gaearon commented Jun 14, 2021

Sorry, this is still a long way from being prod-ready (at least not likely until end of the year) so it's probably not important to fix at this point. I'll revisit this before the release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CLA Signed Resolution: Stale Automatically closed due to inactivity
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants