-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
Revert fs changes #7846
Revert fs changes #7846
Conversation
@thealphanerd: i've gotten bored being tied down by a dependency of a dependency. graceful-fs reverted the proper fix that would have prevented this b/c of wanting ancient node support. though iirc npm no longer supports that version of node, so the fix can land yet again. it's pathetic these need to be reverted. let's prioritize fixing our broken dependency then landing these improvements again. |
Uh-oh. I hope this won't result in a major |
to be honest I'm not that thrilled by this either. Let's get this on the @nodejs/ctc agenda for discussion |
So I did a bit more digging today. There was indeed an issue in graceful-fs regarding how chown was being polyfilled, there is currently a PR in to fix this Even with this fix patched onto npm we are still encountering failures due to other modules in the graceful-fs dep tree that make async fs calls without providing a callback. Due to the way graceful-fs shims chmod, the stack traces are not super useful. It has been suggested in the thread that there may be a more graceful way to handle that situation, by providing a no-op callback to chown. This PR will likely fix the pain point in graceful-fs, but it may take a bit of time. While it may be easy to consider this "another graceful-fs" problem I think it is a sign of wider usage of async functions without a callback in the ecosystem. While doing so is obviously not a best practice, it is happening in the wild, and this change is breaking stuff. @ChALkeR and I were discussing this on IRC and are going to attempt to figure out a list of modules that will break with this change, and will be working on getting updates across the ecosystem to make this change less disruptive. We should revert until the fix to graceful-fs lands, the fix is downstreamed to npm, and we have made a decent effort to make sure the ecosystem breakages are minimal. |
@jasnell, @trevnorris This isn't only graceful-fs fault this time. Even with graceful-fs being patched, there are still errors — it looks like 9359de9 breaks too many modules. Will post the actual results a bit later. |
Yep, understood. I had a chat with @thealphanerd about it earlier this On Monday, July 25, 2016, Сковорода Никита Андреевич <
|
+1 on reverting. I think the realpath situation has shown us we really need to be careful with the impact that breaking changes have on the ecosystem |
For reference isaacs/node-graceful-fs#71 has landed in |
graceful-fs had a bug fix, isaacs/node-graceful-fs#71, which would fix the problem in Node.js nodejs/node#7846
These changes would be released in v7, correct? That is a major release and therefore allowed to be backwards incompatible. While we should not be introducing backwards incompatible changes just for the sake of it, code that omits the callback is borderline broken and I think it's good to turn that into an early error. It's one less avenue for time bombs to sneak into a code base. We shouldn't be afraid to land changes that expose bugs, provided there is an easy way to fix broken code, even when that causes some initial breakage and churn in the ecosystem. Churn because of bugs fixed is good churn. |
@bnoordhuis It should still go through a proper deprecation cycle. Printing a warning at first would be better, I suppose. |
Could we print warnings for now and turn those into errors in v8.0? |
Can we please split this into two separate PRs, one for each revert commit. /cc @nodejs/ctc |
@jasnell the original commit cannot be reverted cleanly without the other commit being reverted first |
This project has a process for making planned breaking changes to core features. It starts with documentation and deprecation warnings, and then the breaking change comes later. Introducing this sort of thing without a warning to the user is irresponsible. Please do not do that. I understand that it's frustrating to work within the constraints imposed by not breaking users' programs. It's frustrating to be responsible sometimes. There are lots of projects out there that don't require this level of responsibility because they aren't popular platforms, but that's what's required to do a good job with this one. These processes are in place to protect the stability of the platform because stability is what matters most for a platform. |
CITGM: https://ci.nodejs.org/view/Node.js-citgm/job/citgm-smoker/344/ (I think that’s what was requested on the CTC meeting, and it won’t hurt anyway.) |
Woo! saved me a step, I was just heading off to do exactly that... |
This reverts commit 9359de9. Original Commit Message: The "fs" module has two functions called `maybeCallback` and `makeCallback`, as of now. The `maybeCallback` creates a default function to report errors, if the parameter passed is not a function object. Basically, if the callback is omitted in some cases, this function is used to create a default callback function. The `makeCallback`, OTOH, creates a default function only if the parameter passed is `undefined`, and if it is not a function object it will throw an `Error`. This patch removes the `maybeCallback` function and makes the callback function argument mandatory for all the async functions. PR-URL: nodejs#7168 Reviewed-By: Trevor Norris <trev.norris@gmail.com>
436a055
to
94e7af6
Compare
94e7af6
to
c5a18e7
Compare
so there are failures in citgm... especially for
All of eslint failures are infra related, they are using a module that doesn't support node v7. Async / request has been known flaky for a while, we just have not been seeing the errors due to a bug in citgm. I'll be digging more into them next week. vinyl-fs has had some problems this past week at all. When I get back next week I'll do a deep dive across all versions and update the flaky status for all modules for all lines |
Can people throw some LGTM's on this? Without this reverted npm is broken on master (has been for almost 2 weeks now) |
Ping @nodejs/ctc |
The CTC decision yesterday was to go ahead with the revert so... LGTM. The bias, however, was towards finding a way for the revert to be temporary. Specifically, the overall opinion appears to be that we want these APIs to throw if a callback is not provided, but we'll just take a bit more time to get there. Emitting either a deprecation warning or process warning ( |
Landed in 21b0a27 |
This reverts commit 9359de9. Original Commit Message: The "fs" module has two functions called `maybeCallback` and `makeCallback`, as of now. The `maybeCallback` creates a default function to report errors, if the parameter passed is not a function object. Basically, if the callback is omitted in some cases, this function is used to create a default callback function. The `makeCallback`, OTOH, creates a default function only if the parameter passed is `undefined`, and if it is not a function object it will throw an `Error`. This patch removes the `maybeCallback` function and makes the callback function argument mandatory for all the async functions. PR-URL: #7168 Reviewed-By: Trevor Norris <trev.norris@gmail.com> PR-URL: #7846 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com>
Adding the don't land on v6.x label, as this reverts a semver major change. |
@cjihrig ... I believe reverting these in v6 is something that we need to do and was discussed on the @nodejs/ctc call. Specifically, the plan is to back off throwing when the callback is not given and to issue a deprecation warning instead. Throwing just caused too much breakage in the ecosystem. @nodejs/ctc @thealphanerd ... does this match your recollection? |
-.- ... heh, you're right, of course. I keep thinking that this one had landed in v6 but I keep confusing it with the other fs changes. |
Yea, |
Fix bug in chmod wrapper that was tickled by recent node.js changes. (nodejs/node#7846) PR-URL: isaacs/node-graceful-fs#71 Credit: @thefourtheye Reviewed-By: @isaacs
graceful-fs had a bug fix, isaacs/node-graceful-fs#71, which would fix the problem in Node.js nodejs/node#7846 PR-URL: #13497 Credit: @thefourtheye Reviewed-By: @iarna
Checklist
make -j4 test
(UNIX), orvcbuild test nosign
(Windows) passesAffected core subsystem(s)
fs
Description of change
9359de9 and c86c1ee are two semver major changes to the fs module that landed in the last 24 hours. When trying to run CITGM it was discovered that
npm set
was throwing an errorI think that we should revert asap and revisit these two commits in a new PR to figure out what is going on here
edit: it looks like the problem may be in graceful-fs. I'm going to dig into finding a fix for it, I will also look into adding it to citgm, as it has definitely been a module that has caused pain in the past