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

Semver-major changes #173

Open
wants to merge 34 commits into
base: main
Choose a base branch
from
Open

Conversation

coreyfarrell
Copy link
Collaborator

I can break this into smaller PR's if that makes it easier to review. This enables 100% coverage, adds osx to the travis config (lutimes polyfills can only be tested on osx). Note the first 3 commits in this PR are already submitted to #169.

One thing I'm not thrilled about is how fs.promises.open is implemented. The first call to fs.promises.open may be slightly delayed while the system finishes patching that function. Specifically we need the native C++ FileHandle and the JavaScript class FileHandle from lib/internal/fs/promises.js. The native C++ FileHandle is acquired through the process.binding('fs').FileHandle which is deprecated. The only way to get class FileHandle is by calling the original await fs.promises.open and finding the constructor of the result. Access to the native C++ FileHandle is required to support automagic closing of unclosed fd's on garbage collection. Access to the JS class FileHandle is required to allow us to extend the base class, otherwise we would have to reimplement all functions and this would potentially have other negative effects.

Fixes #152
Fixes #160
Fixes #167
Fixes #170


Breaking Changes

  • Require node.js 8
  • Drop legacy polyfilling
  • Properly handle DEP0013 based on node.js runtime version (warn in node.js 8/9, throw in 10+)

Features

  • Patch fs.promises where available (node.js 10+). Note first access to require('graceful-fs').promises accesses fs.promises so in node.js 10 it will trigger the experimental feature warning.

Fixes

  • Honor autoClose: false in WriteStream.open
  • Prevent accidental monkey-patching of fs.ReadStream / fs.WriteStream
  • Prevent multiple patching of process.cwd, process.chdir
  • Emit ready event upon stream open

Refractors

  • Modernize code
  • Unify ENFILE/EMFILE patches
  • Unify chmod/chown patches
  • Unify stream patches
  • Drop TEST_GRACEFUL_FS_GLOBAL_PATCH, test with gfs.gracefulify
  • Eliminate GRACEFUL_FS_PLATFORM, move Windows polyfills to separate files to allow direct testing
  • Move lutimes patches to separate file to allow ignoring coverage when unsupported
  • Use fs.mkdtempSync in tests (this will allow parallel testing once Support for repeating test files with multiple env settings tapjs/tapjs#586 is resolved)

Importing a fresh copy of graceful-fs then using `require('fs').close`
would only initiate retry of the queue from the first copy of
graceful-fs, so needed retries associated with subsequent instances of
graceful-fs would not be executed.
Some changes in the previous commit are not needed in v4.x which will
never be tested under nyc.  The only thing needed is the ability for the
next version of graceful-fs to reset fs.close / fs.closeSync.
This was for an issue with versions of node.js that are EOL.
Node.js commits which fixed this issue:
* v4.6.2+ - nodejs/node@3d6f107a2f
* v6.8.0+ - nodejs/node@07d97f4f3e
* v7.0.0+ - nodejs/node@3d6f107a2f

Also remove associated testing.
Properly handle DEP0013 in ENFILE/EMFILE patched functions depending
on node.js version.
* Add autoClose support to WriteStream.open
* Prevent accidental monkey-patching of fs.*Stream
Properly handle DEP0013 in patched fs.close.
Process callback argument to ensure proper handling if missing.
* Create windows-rename-polyfill.js
* Eliminate process.env.GRACEFUL_FS_PLATFORM
* Modernize windows-rename-polyfill test
* Prefer const
* Space before function parentheses
* Remove unused args
@coreyfarrell
Copy link
Collaborator Author

So far the only reaction to nodejs/node#29109 has been negative. I'm not sure it's a great idea to publish the promises feature without a path out of hack-land. I'm inclined to say lets hold this for a bit to see what happens over in node.js.

@coreyfarrell
Copy link
Collaborator Author

Additionally I'd like to see where things go with some active PR's against node.js fs streams. In particular I think [email protected] should conditionally use whatever options are eventually provided by nodejs/node#29083, the less we override the better.

* Avoid process.binding
* Monkey-patch promises FileHandle.close to call retry
* Do not use promisify
* Eliminate delay on first open
"glob": "^7.1.4",
"import-fresh": "^3.1.0",
"nyc": "^14.1.1",
"rimraf": "^2.6.3",
Copy link

Choose a reason for hiding this comment

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

Seems to be up to [email protected], as I proposed in PR #177

@brodycj
Copy link

brodycj commented Nov 24, 2019

Any news on this one?

@coreyfarrell
Copy link
Collaborator Author

@brodybits on hold for nodejs/node#29083. I think the last CI blocker was just fixed in the PR so hopefully that can be merged soon. Once it's merged and (hopefully) backported to 13.x I'll be updating here to use that feature when possible and will refresh latest versions of all dependencies.

@ronag
Copy link

ronag commented Dec 18, 2019

FYI nodejs/node#29083 is now merged. It was merged as semver-minor and I believe it should be included in node 13.6.0 or soon thereafter.

@brodycj
Copy link

brodycj commented Dec 18, 2019

  • Patch fs.promises where available (node.js 10+).

I would favor dropping Node.js 8 support since it is near EOL.

@coreyfarrell
Copy link
Collaborator Author

@ronag thanks for the update. I'll update this once fs stream overrides are in a release (I will need a check against process.versions.node to detect that feature).

@brodybits node.js support will be up to @isaacs. Worth noting the detection of fs.promises is relatively simple, dropping node.js 8 would not result in significantly decreased complexity, so really it's only a question of possibly holding back development dependencies (this is not a concern for end users).

@brodycj
Copy link

brodycj commented Dec 19, 2019

Thanks @coreyfarrell. My idea was that dropping Node.js 8 would reduce burden of future updates for the next 1-2 years or so. Just an idea:)

@zkochan zkochan mentioned this pull request Jun 4, 2020
@zkochan
Copy link

zkochan commented Jun 7, 2020

Why does it take so long to merge this?

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