GeezerVison

This does not cancel the fact that npm has to update graceful-fs inside it, but this should give a grace period to other users of graceful-fs instead of suddenly breking their setups with a bogus error message in 6.0.

Hmmmm, would it be possible to use process.bindings('natives') ourselves to load the internal code? Arguably it'd be more robust against changes?

Is it possible and not-onerous to write a test for this? EDIT: Like, maybe something that confirms that a sensible-ish message is being provided when the situation arises?

LGTM with a nit

As per #4525 (comment) I'm suggesting we also go with just removing #4525 from v5.x for now to give us breathing room.

This solution is kind of gross but lgtm since there's no other good way around it as far as I can tell.

@rvagg Why was a semver-major commit landed on v5.x?

sorry, wires crossed, ignore my comment

@Fishrock123

Hmmmm, would it be possible to use process.bindings('natives') ourselves to load the internal code? Arguably it'd be more robust against changes?

The warning (and an error in 7.0) is only thrown if it's not possible to load internal/util. If that code is re-executed where internal is allowed (including user code with --expose-internals flag) there would not be any warning or error.

LGTM. Should we have a tracking issue to have the npm's dependency upgradation?

LGTM if it works and Ci is happy

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

Also worth mentioning that I just submitted #5166 which tests the edge case this broke (re: npm).

@Trott, I have pending tests for this, but let's put those in a separate PR, because I am not yet sure with those and adding them would delay getting master fixed. I don't want getting #4525 reverted :-)

@ChALkeR feel free to cherry-pick my test 😄 :
MylesBorins@91b4f79

-1. this is just ridiculous

@thealphanerd, it's not directly related. Your test is for npm and it's good to have it long-term, mine is for old versions of graceful-fs-like code and will be reverted in 7.0. I would want both of those, separately.

@vkurchatkin

-1. this is just ridiculous

ok, so now we don't have consensus on this PR, and I don't imagine we are getting it soon. Can we please revert the original PR and reopen it so that we can fix master.

edit: I want to add that I do not think that reverting means the other should not land again, and potentially not land again quickly. master has been effectively broken since Friday, and I feel a sense of urgency to get things working again.

Correct me if I'm wrong, but shouldn't this be dont-land-on-v5.x rather than semver-major?

@Fishrock123 indeed.

@thealphanerd This is not semver-major itself, but it depends on a semver-major commit (and adds a temporary fix on top of it).

Perhaps someone find it useful - not a solution, but a temporary walk-around for graceful-fs and alike modules: https://gist.github.com/bondden/2d2e07d18d94d1f4dc23b7dcf9b0e350

@ChALkeR I'm not sure that the error message in this PR is very helpful to users. Almost every single app or node script that I run now displays this message.

For example, when building Atom:

Installing build modules...
(node:2342) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
(node:2342) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
(node:2342) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
(node:2342) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
(node:2342) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
(node:2342) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
(node:2342) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
(node:2342) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
(node:2342) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
=> Took 7025ms.

Or when running an Ember app:

(node:2792) fs: re-evaluating native module sources is not supported. If you are using the graceful-fs module, please update it to a more recent version.
WARNING: Node v6.2.0 has currently not been tested against Ember CLI and may result in unexpected behaviour.
version: 1.13.13
Livereload server on http://localhost:49152
Serving on http://localhost:4300/

The message doesn't show a stack trace, nor is it clear what module the problem is originating from, so there's no easy way to find out where to go to ask for a fix or what package to update.

Can this message be updated to be a bit more descriptive and maybe limit the amount of times it's shown? In it's current form, while it's not an error, it's not very useful and I feel it will still cause a lot of confusion amongst users.

@adambuczynski

there's no easy way to find out where to go to ask for a fix or what package to update.

I haven't seen any real-world case when it wasn't caused by a graceful-fs 2.x or 3.x dependency. Everyone should just bump their graceful-fs dependencies to 4.x. You can use npm list graceful-fs to see why it was installed.

and maybe limit the amount of times it's shown?

It is already limited to 1 time per node process, unleast you have multiple old versions of graceful-fs installed, all of which should be updated. It looks reasonable to me to just print the message several times then, given that the code to track this further would introduce other undesired changes (storing a flag in another module, storing a flag in global scope, etc.).

I haven't seen any real-world case when it wasn't caused by a graceful-fs 2.x or 3.x dependency. Everyone should just bump their graceful-fs dependencies to 4.x. You can use npm list graceful-fs to see why it was installed.

Ideally, yes everyone should do that. But by everyone you mean package maintainers, and package maintainers can only realistically be asked to maintain the dependencies of their own package.

I have the same gripe with this "error" message as with the "prefer global" warning that npm gives for nested packages (See npm/npm#11652)

End users or a package or script don't really care if some nested package of some dependency somewhere down the line in the dependency tree has a deprecated fs-graceful.

Basically I feel that this deprecation warning should be thrown by npm at install time rather than node at runtime, and only when you have the old version of fs-graceful in your dependencies, encouraging you to update your dependencies. I don't care what packages atom uses and what dependencies those packages have, I just want to be able to run the build script without seeing these ugly warnings all over the place :)

It is already limited to 1 time per node process, unleast you have multiple old versions of graceful-fs installed, all of which should be updated. It looks reasonable to me to just print the message several times then, given that the code to track this further would introduce other undesired changes (storing a flag in another module, storing a flag in global scope, etc.).

Ok I didn't know that, yes fair enough.

@adambuczynski

Basically I feel that this deprecation warning should be thrown by npm at install time

It is thrown at both install time and in runtime. Just install time is not an option, because we can't guarantee that it's caused by graceful-fs in all cases, and a proper deprecation warning is needed here to make sure that users are notified of the future change.

The message doesn't show a stack trace

You can use --trace-deprecation to get a stack trace, when you are running an application.

Note that those versions of graceful-fs will simply cause an error in future versions of node and refuse to run at all. The more people notice it, come ask questions / anything else, the better.

You can use --trace-deprecation to get a stack trace, when you are running an application.

Not really, when I build Atom I just run script/build, and I don't think it supports node arguments.
Hence my point about end users having no use for those messages/errors and no easy way of dealing with them.

Note that those versions of graceful-fs will simply cause an error in future versions of node and refuse to run at all. The more people notice it, come ask questions / anything else, the better.

Let's hope it works and the messages are banished from our world within a week or two :)

Not really, when I build Atom I just run script/build, and I don't think it supports node arguments.

That's not really our fault. The flags for deprecations have been around for years. You should probably check, and if it is not capable of passing flags, we should probably prompt them for at least --trace-deprecation and --trace-warning to be made available.

Of course, I'm not saying it is, but the point I'm trying to make is that even if it were available, I am not a developer or maintainer of Atom. As such, I don't care if their build script has deprecations or warnings because of the packages it (or its dependencies) use. I just want it to run and build the latest version of Atom for me without nagging me about the same deprecation 20 times :)

Those errors are good for developers / package maintainers to see and get warned about, not so much end users. I understand it's hard from a Node perspective to differentiate between the two, and that's why I thought it would be sufficient to issue deprecation warnings when a package installs the deprecated dependency.

However as ChALkeR mentioned that's not an option here, so we're kind of stuck with this message it seems.

Help Me to solve this problem.
I am unable to use angular IDE

npm ERR! Linux 4.4.0-63-generic
npm ERR! argv "/usr/bin/nodejs" "/usr/bin/npm" "install" "-g" "graceful-fs" "graceful-fs@latest-version"
npm ERR! node v4.2.6
npm ERR! npm v3.5.2

npm ERR! No compatible version found: graceful-fs@latest-version
npm ERR! Valid install targets:
npm ERR! 4.1.11, 4.1.10, 4.1.9, 4.1.8, 4.1.7, 4.1.6, 4.1.5, 4.1.4, 4.1.3, 4.1.2, 4.1.1, 4.1.0, 3.0.11, 3.0.10, 3.0.9, 3.0.8, 3.0.7, 3.0.6, 3.0.5, 3.0.4, 3.0.3, 3.0.2, 3.0.1, 3.0.0, 2.0.3, 2.0.2, 2.0.1, 2.0.0, 1.2.3, 1.2.2, 1.2.1, 1.2.0, 1.1.14, 1.1.13, 1.1.12, 1.1.11, 1.1.10, 1.1.9, 1.1.8, 1.1.7, 1.1.6, 1.1.5, 1.1.4, 1.1.3, 1.1.2, 1.1.1, 1.1.0, 1.0.2, 1.0.1, 1.0.0
npm ERR!
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR! https://github.com/npm/npm/issues

npm ERR! Please include the following file with any support request:
npm ERR! /home/bosco/npm-debug.log

@maniJoe Post questions at https://github.com/nodejs/help/issues, don't spam random issues.