lib,fs: use process.emitWarning instead of internal print dep warning #8166

jasnell · 2016-08-18T19:15:57Z

Checklist

make -j4 test (UNIX), or vcbuild test nosign (Windows) passes
commit message follows commit guidelines

Affected core subsystem(s)

lib, fs

Description of change

This removes uses of the the internal/util printDeprecationMessage() API in favor of
using process.emitWarning(msg, 'DeprecationWarning'). This allows us to remove the
graceful-fs warning in fs providing at least a temporary relief of the logjam that is
occurring there.

The PR also adds a new lint rule that flags uses of printDeprecationMessage()

/cc @ChALkeR @thealphanerd @nodejs/ctc

This is an alternative to #6413. If this lands, We do not have to do the revert.

ChALkeR · 2016-08-18T19:31:45Z

Sorry, but -1 on that until #6413 gets merged. We should keep the warning there until it's broken, else we will need to re-implement the warning.

Because other PRs (I counted four of them) are blocked by the exact same thing — and we don't want those to be broken without a warning.

That warning is not a culpit, it's just the messenger, just removing it for the sake of removing would do no good, if other PRs will block on that again.

After #6413 and other breaking PRs get merged, +1 on this change as a regular clean up, but not as an alternative to #6413.

jasnell · 2016-08-18T19:38:30Z

I understand that the same fundamental problem exists still but this would eliminate the immediate issue giving us more time to address the larger concern without jamming anything up on this one thing. It's an incremental step not a final solution.

vkurchatkin · 2016-08-18T19:43:09Z

I don't understand, why it is removes from all modules, not just fs?

ChALkeR · 2016-08-18T19:43:33Z

@jasnell Once again: evading the breaking change in #6413 would not give us anything, because there are several more PRs that break graceful-fs evildoing in exactly the same way. That's why the fix in graceful-fs@3 (isaacs/node-graceful-fs@07701dc) also wouldn't work generally.

Moreover — #6413 doesn't even break graceful-fs anymore, as the hack was landed in graceful-fs (which I am not happy about, because it gives us nothing).

The issue here is with other PRs which get blocked by keeping graceful-fs@3 compatibility, and that's what we need to fix. Removing the deprecation warning would make things even worse, I think. We still address the issue that blocks those PR as «#6413», but that's not even correct anymore — it's only a label for the issue atm as #6413 could be merged at any time with no effect on graceful-fs@3.

ChALkeR · 2016-08-18T19:46:40Z

@jasnell I would be completely fine with merging this as a regular clean up if the deprecation warning is kept and if we will have a separate PR that would turn the deprecation warning into a throw instead of #6413, so that we could block all those PRs against that instead of #6413.

-1 is only for the removal of the warning without making it a throw.

For the record, a list of PRs why we need the warning: #6749, #6573, #7162, #2025 (that last one is closed, but it got closed because of graceful-fs hack support, it actually does a good thing).

Any of those would break graceful-fs@[23], and we don't want that to be a sudden breakage. The warning is required so that people stop using graceful-fs@[23] so we could merge those.

jasnell · 2016-08-18T20:05:10Z

@ChALkeR ... just so I understand... are you specifically talking about the graceful-fs warning?

ChALkeR · 2016-08-18T20:06:44Z

@jasnell I am talking about the fs: re-evaluating native module sources is not supported. … warning that is currently triggered on the Node.js side when someone tries to re-evaluate core fs moule sources (namely, graceful-fs@2 and graceful-fs@3).

jasnell · 2016-08-18T20:07:53Z

@vkurchatkin ... if you look at the implementation of internal/util#printDeprecationMessage, you'll see that all it does is defer to process.emitWarning(). Accordingly, it doesn't make sense to keep using printDeprecationMessage since we can use emitWarning() directly.

vkurchatkin · 2016-08-18T20:37:00Z

but why create eslint rule for that? let's just remove printDeprecationMessage

jasnell · 2016-08-18T20:41:39Z

We can do that also. My plan was to reevaluate the methods in internal/util separately and remove stuff that's unnecessary in a separate PR, but you're right that this would allow us to go ahead and remove printDeprecationMessage() now.

Trott · 2016-08-18T20:49:07Z

Nit: I would prefer a clearer name for the rule and rule file. dep is more likely to be read as "dependency" or something like that at first glance and not deprecation. Maybe no-internal-dep -> no-internal-deprecation at a minimum? I'm fine with the rule being long. There's already longer built-in rule names like no-whitespace-before-property.

jasnell · 2016-08-18T21:19:02Z

@vkurchatkin @ChALkeR .. ok, refactored the PR.

The internal/util printDeprecationMessage() method is removed entirely
The reevaluation warning is added back into fs but without the need for polyfilling printDeprecationMessage()
I had to include a fix to emitWarning because it wasn't handling process.noDeprecation correctly (bug that wasn't caught previously)

ChALkeR · 2016-08-18T21:23:11Z

lib/fs.js

@@ -15,6 +15,18 @@ const EventEmitter = require('events');
 const FSReqWrap = binding.FSReqWrap;
 const FSEvent = process.binding('fs_event_wrap').FSEvent;

+// Check for re-evaluation of the module. Doing so will cause the internal
+// module to fail to load.


Could you keep the TODO and reasoning? It might need a slight rephrase, e.g.:

// TODO(ChALkeR): remove this in master after 6.x // This is required to give users a grace period before actually breaking // modules that re-evaluate fs sources from context where internal // modules are not allowed, e.g. older versions of graceful-fs module.

Yeah, will add that back

ChALkeR · 2016-08-18T21:25:44Z

@jasnell Thanks!

+1 to the current approach. This is not a complete review, I will review the actual code changes tomorrow =).

jasnell · 2016-08-18T21:29:43Z

@Trott ... I just removed the eslint rule but thank you for the feedback on it :-)

ChALkeR · 2016-08-18T21:54:12Z

lib/fs.js

@@ -15,8 +15,11 @@ const EventEmitter = require('events');
 const FSReqWrap = binding.FSReqWrap;
 const FSEvent = process.binding('fs_event_wrap').FSEvent;

+// TODO(ChALkeR,jasnell): remove the following try/catch in master after 7.x


I'm still hoping we could remove the warning and land other PRs in time to v7.0 release, as the ecosystem packages actually could get fixed in time to v7.0 release.

Atm, this comment contradicts our milestones, specifically, milestone for #6573 — if that lands in v7.0, then this warning would be useless in v7.0.

jasnell · 2016-08-18T22:09:05Z

@ChALkeR I know.. this reflects the current status I think but if we can clear up the logjam before v7 then fantastic...

jasnell · 2016-08-21T21:45:02Z

@nodejs/ctc ... PTAL

jasnell · 2016-08-23T17:55:19Z

Ping @nodejs/ctc @nodejs/collaborators

ChALkeR · 2016-08-25T10:49:45Z

lib/fs.js

+// Check for re-evaluation of the module. Doing so will cause the internal
+// module to fail to load. This is required to give users a grace period before
+// actually breaking modules that re-evaluate fs sources from context where
+// internal modules are not allowed, e.g. older versions of graceful-fs module.


Note that this is still valid (even with the most recent graceful-fs@3 update) for users of graceful-fs@2, older versions of graceful-fs@3, and perhaps some user code that does the same thing (unlikely, but still possible).

Removing the warning would force us to introduce it again at least for a full major cycle in order to land other PRs that are blocked by re-evaluating fs.

So, please don't remove this on updates =).

jasnell · 2016-08-25T14:38:54Z

New CI: https://ci.nodejs.org/job/node-test-pull-request/3832/
(the last one uncovered a bug.. updated)

jasnell · 2016-08-25T15:08:43Z

CI is green

jasnell · 2016-08-30T17:12:51Z

@ChALkeR ... PR updated, PTAL

jasnell · 2016-08-30T17:13:22Z

CI: https://ci.nodejs.org/job/node-test-pull-request/3890/

MylesBorins · 2016-08-30T17:15:17Z

LGTM

jasnell · 2016-08-30T18:07:52Z

Flaky failure in arm, CI is green otherwise.

jasnell · 2016-08-30T19:58:18Z

Will land this tomorrow if there are no objections.

ChALkeR · 2016-08-30T20:07:11Z

lib/fs.js

@@ -40,7 +40,6 @@ const isWindows = process.platform === 'win32';

 const DEBUG = process.env.NODE_DEBUG && /fs/.test(process.env.NODE_DEBUG);
 const errnoException = util._errnoException;
-const printDeprecation = require('internal/util').printDeprecationMessage;


Could you leave require('internal/util'); here so this won't become suddenly re-evaluatable in v7? Or we might be forced to do another round of deprecation…

That line could be removed when something else will land that requires internal, hopefully in time for v7.

Upd: not needed anymore, as #6749 landed.

There are several other open PRs that move bits to internal/fs.js that would cover this requirement.

Only if those land before this one =).

@ChALkeR ... #6749 landed just now, which adds a ref to internal/fs

Yay!
That discards my previous comments in this subthread =).

The process.emitWarning() API should be used for printing deprecation warning messages rather than directly using the internal/util#printDeprecationMessage

As an alternative to nodejs#6413, use process.emitWarning() instead of the internal printDeprecationMessage in order to avoid use of an internal only API.

Removes the internal/util printDeprecationWarning method

jasnell · 2016-09-02T19:47:53Z

New CI before landing: https://ci.nodejs.org/job/node-test-pull-request/3930/

jasnell · 2016-09-02T20:14:23Z

CI is green-ish. Only build bot failures that will hopefully be fixed soon. Landing!

PR-URL: #8166 Reviewed-By: Сковорода Никита Андреевич <[email protected]> Reviewed-By: Myles Borins <[email protected]>

The process.emitWarning() API should be used for printing deprecation warning messages rather than directly using the internal/util#printDeprecationMessage PR-URL: #8166 Reviewed-By: Сковорода Никита Андреевич <[email protected]> Reviewed-By: Myles Borins <[email protected]>

Use process.emitWarning() instead of the internal printDeprecationMessage in order to avoid use of an internal only API. PR-URL: #8166 Reviewed-By: Сковорода Никита Андреевич <[email protected]> Reviewed-By: Myles Borins <[email protected]>

Removes the internal/util printDeprecationWarning method PR-URL: #8166 Reviewed-By: Сковорода Никита Андреевич <[email protected]> Reviewed-By: Myles Borins <[email protected]>

jasnell · 2016-09-02T20:17:44Z

Landed in bf91035, 15eaba9, b50557b, and 7b73f55

jasnell · 2016-09-02T20:18:44Z

Marking as don't land on v6 or v4 due to the potential legacy graceful-fs impact.

Cherry-picked from: PR-URL: nodejs#8166 Reviewed-By: Сковорода Никита Андреевич <[email protected]> Reviewed-By: Myles Borins <[email protected]>

jasnell added fs Issues and PRs related to the fs subsystem / file system. lib / src Issues and PRs related to general changes in the lib or src directory. labels Aug 18, 2016

nodejs-github-bot added util Issues and PRs related to the built-in util module. module Issues and PRs related to the module subsystem. timers Issues and PRs related to the timers subsystem / setImmediate, setInterval, setTimeout. labels Aug 18, 2016

jasnell changed the title ~~Use emitwarning~~ lib,fs: use process.emitWarning instead of internal print dep warning Aug 18, 2016

jasnell force-pushed the use-emitwarning branch from 499ae6f to 810605a Compare August 18, 2016 21:16

ChALkeR reviewed Aug 18, 2016
View reviewed changes

jasnell mentioned this pull request Aug 18, 2016

POC: Introduce Node.js 6+ compatibility mode for gulp@3 gulpjs/gulp#1760

Closed

ChALkeR reviewed Aug 18, 2016
View reviewed changes

This was referenced Aug 19, 2016

fs: warn instead of throwing if no callback #7897

Closed

buffer: hard-deprecate calling Buffer without new #8169

Closed

ChALkeR reviewed Aug 25, 2016
View reviewed changes

jasnell mentioned this pull request Aug 25, 2016

Revert "fs: add a temporary fix for re-evaluation support" #6413

Closed

2 tasks

jasnell force-pushed the use-emitwarning branch from 12d6a6d to 6fa6514 Compare August 30, 2016 17:12

ChALkeR reviewed Aug 30, 2016
View reviewed changes

jasnell added 4 commits September 2, 2016 10:51

process: fix handling of process.noDeprecation in emitWarning

46a69b4

lib: use emitWarning instead of printDeprecationMessage

5aa3ea2

The process.emitWarning() API should be used for printing deprecation warning messages rather than directly using the internal/util#printDeprecationMessage

fs: use process.emitWarning to print deprecation warning

09d97e9

As an alternative to nodejs#6413, use process.emitWarning() instead of the internal printDeprecationMessage in order to avoid use of an internal only API.

internal/util: remove printDeprecationWarning

2ef2c7f

Removes the internal/util printDeprecationWarning method

jasnell force-pushed the use-emitwarning branch from 6fa6514 to 2ef2c7f Compare September 2, 2016 17:51

jasnell added a commit that referenced this pull request Sep 2, 2016

process: fix handling of process.noDeprecation in emitWarning

bf91035

PR-URL: #8166 Reviewed-By: Сковорода Никита Андреевич <[email protected]> Reviewed-By: Myles Borins <[email protected]>

jasnell closed this Sep 2, 2016

jasnell added dont-land-on-v4.x labels Sep 2, 2016

jasnell mentioned this pull request Sep 2, 2016

process: fix handling of process.noDeprecation in emitWarning #8394

Closed

2 tasks

gibfahn mentioned this pull request Jun 15, 2017

Auditing for 6.11.1 nodejs/Release#230

Closed

3 tasks

lib,fs: use process.emitWarning instead of internal print dep warning #8166

lib,fs: use process.emitWarning instead of internal print dep warning #8166

Conversation

jasnell commented Aug 18, 2016 • edited Loading

Checklist

Affected core subsystem(s)

Description of change

ChALkeR commented Aug 18, 2016 • edited Loading

jasnell commented Aug 18, 2016

vkurchatkin commented Aug 18, 2016

ChALkeR commented Aug 18, 2016 • edited Loading

ChALkeR commented Aug 18, 2016 • edited Loading

jasnell commented Aug 18, 2016

ChALkeR commented Aug 18, 2016 • edited Loading

jasnell commented Aug 18, 2016

vkurchatkin commented Aug 18, 2016

jasnell commented Aug 18, 2016

Trott commented Aug 18, 2016

jasnell commented Aug 18, 2016

ChALkeR Aug 18, 2016 • edited Loading

Choose a reason for hiding this comment

jasnell Aug 18, 2016

Choose a reason for hiding this comment

ChALkeR commented Aug 18, 2016 • edited Loading

jasnell commented Aug 18, 2016

ChALkeR Aug 18, 2016

Choose a reason for hiding this comment

jasnell commented Aug 18, 2016 • edited Loading

jasnell commented Aug 21, 2016

jasnell commented Aug 23, 2016

ChALkeR Aug 25, 2016 • edited Loading

Choose a reason for hiding this comment

jasnell commented Aug 25, 2016

jasnell commented Aug 25, 2016

jasnell commented Aug 30, 2016

jasnell commented Aug 30, 2016

MylesBorins commented Aug 30, 2016

jasnell commented Aug 30, 2016

jasnell commented Aug 30, 2016

ChALkeR Aug 30, 2016 • edited Loading

Choose a reason for hiding this comment

jasnell Sep 1, 2016

Choose a reason for hiding this comment

ChALkeR Sep 1, 2016

Choose a reason for hiding this comment

jasnell Sep 2, 2016

Choose a reason for hiding this comment

ChALkeR Sep 2, 2016

Choose a reason for hiding this comment

jasnell commented Sep 2, 2016

jasnell commented Sep 2, 2016

jasnell commented Sep 2, 2016

jasnell commented Sep 2, 2016

jasnell commented Aug 18, 2016 •

edited

Loading

ChALkeR commented Aug 18, 2016 •

edited

Loading

ChALkeR commented Aug 18, 2016 •

edited

Loading

ChALkeR commented Aug 18, 2016 •

edited

Loading

ChALkeR commented Aug 18, 2016 •

edited

Loading

ChALkeR Aug 18, 2016 •

edited

Loading

ChALkeR commented Aug 18, 2016 •

edited

Loading

jasnell commented Aug 18, 2016 •

edited

Loading

ChALkeR Aug 25, 2016 •

edited

Loading

ChALkeR Aug 30, 2016 •

edited

Loading