Info, rather than Warn, when skipping packages not suitable to target OS

[mikemaccana]

Per #10768, many users are confused by the message NPM shows when skipping packages not relevant to target OS:

Currently:

npm WARN optional Skipping failed optional dependency /chokidar/fsevents:
npm WARN notsup Not compatible with your operating system or architecture: fsevents@1.0.7

Suggest:

npm INFO optional Skipping optional dependency /chokidar/fsevents:
npm INFO notsup Not compatible with your operating system or architecture: fsevents@1.0.7

I.e, remove the word 'failed' and use 'INFO' instead of 'WARN'

[bendavis78]

This should really be a DEBUG level message and not shown at all by default. If an optional dependency isn't meant for my OS, there's no reason I need to know about it. The way the error message is written, it still looks like an error. Plus, npm already doesn't tell me whether or not install was successful, so when I get any output from npm my first reaction is to think it's an error.

[simonbuchan]

I'm fine with this being a WARN if it's only shown when it would be installed if it was supported:

$ npm i -S glob
test-npm@ C:\code\test-npm
`-- glob@7.0.3
  <snip>
$ npm i

Yay, no output when nothing happened!

$ npm i -S chokidar
test-npm@ C:\code\test-npm
`-- chokidar@1.5.0
  <snip>
npm WARN optional Skipping failed optional dependency /chokidar/fsevents:
npm WARN notsup Not compatible with your operating system or architecture: fsevents@1.0.12

OK, it tried and failed to install something, that's reasonable.

$ npm i
npm WARN optional Skipping failed optional dependency /chokidar/fsevents:
npm WARN notsup Not compatible with your operating system or architecture: fsevents@1.0.12

Boo! It did nothing, nothing has changed, there's no reason to complain!

$ npm i -S object-assign
test-npm@ C:\code\test-npm
`-- object-assign@4.1.0

npm WARN optional Skipping failed optional dependency /chokidar/fsevents:
npm WARN notsup Not compatible with your operating system or architecture: fsevents@1.0.12

Boo! object-assign installed fine and problem free, there shouldn't be a warning!

I suggest adding, for a strawman, _failedDependencies.fsevents: "1.0.12" to node_modules/chokidar/package.json so npm knows at least not to message again, and maybe it can know to not bother trying to install again.

[jods4]

+1
This should be given a higher priority (the problem exists at least since Dec 2015), especially since it's a trivial fix.

This is not just a semantic / nitpicker question. Using WARN rather than INFO triggers some downstream tooling errors, see the issue Kukkimonsuta linked above. It is highly annoying to see a yellow warning sign in your tools when everything is OK. Moreover, you end up ignoring it, which may hide other issues.

[Vanuan]

Is is possible to tell npm to stop downloading that package?

npm info attempt registry request try #1 at 8:48:59 PM
npm http request GET https://registry.npmjs.org/fsevents

It happens on every npm install even though it's already cached.

[gigablox]

Yea this is super obnoxious from a devops perspective. WARN's usually mean I need to investigate something and now I'm deviating build script code to let these types of exceptions run by.

[Vanuan]

The problem here is the http fetch, not the warning itself.

Some people suggest using npm install --no-optional.

[LufoX11]

This should really be a DEBUG level message and not shown at all by default. If an optional dependency > isn't meant for my OS, there's no reason I need to know about it. The way the error message is written, it > still looks like an error.

100% right. I'm here because I thought it was an error.

[Vanuan]

There is a reason. Otherwise you wouldn't know why npm install is so slow. Even if you already run it.

[jods4]

@Vanuan

The problem here is the http fetch, not the warning itself.

Reading the OP again, I really think this issue is about reporting WARN vs INFO.
Maybe you need to open another issue if you have trouble with the http fetch.

And I really wish someone would do something about this! 😡 I really don't like ignoring all warnings when I run my toolchain, it makes me feel that one day I'll have a real problem.

[Vanuan]

it makes me feel that one day I'll have a real problem.

But you do have a real problem. If you want to ignore optional dependencies, use --no-optional

[jods4]

@Vanuan Sorry but I don't get you.
fsevents is the implementation strategy of chokidar on Mac OS-X, using FSEvents native API.
I run on Windows, where Chokidar uses another strategy. Where is my real problem?

If you want to ignore optional dependencies, use --no-optional

What if I don't want to ignore all of them? Imagine there is an optional package to use Windows native file watchers, you're telling me that I can't use it?

What if I can't control that flag? As others have mentioned before, npm is called by other tools, like Visual Studio.

In the end, the problem is that NPM doesn't follow what is generally considered an ERROR vs a WARNING vs an INFO. And it would be nice to fix it.

[Vanuan]

I agree, that --no-optional is not a best workaround. But hiding a problem is a poor one.

The proper workaround would be that npm somehow remembers which optional dependency installs have already failed and skips trying reinstalling them. We'd still have a warning on the very first npm install as package.json format doesn't support platform-specific dependencies, and optional dependencies are being abused.

The solution would be to add support of platform-specific dependencies.

[rodriguezmilton]

Hi there !
I totally agree with @jods4.
The best workaround I found is going back to previous versions and wait for npm to solve this problem. I think it's better than --no-optional.
Let's wait for them to fix it soon :)

[rjgotten]

The proper workaround would be that npm somehow remembers which optional dependency installs have already failed and skips trying reinstalling them. We'd still have a warning on the very first npm install as package.json format doesn't support platform-specific dependencies, and optional dependencies are being abused.

And on that very first npm install we'd still have downstream tooling break when a warning is output over stderr. So no; that's not a proper workaround.

The correct workaround is to either stop treating errors in optional dependencies as warnings, or to stop outputting warnings on stderr and only report actual errors there.

[Vanuan]

Ok. So there are the following subissues caused by platform (in)compatibility:

1. CI use case (tooling can't ignore a specific warning)

2. Developer use case

   a. developers are confused
   b. npm install is longer than needed

Workaround to the first issue is to patch your tooling

[rjgotten]

Workaround to the first issue is to patch your tooling

Which is a no-go in case of closed source tooling. E.g. Visual Studio.

[jods4]

Workaround to the first issue is to patch your tooling

LOL, seriously? Workaround to NPM raising warnings when they are meaningless is to patch all the tools?
What about patching NPM instead?

[Vanuan]

That's a difference between workaround and solution.

Which is a no-go in case of closed source tooling. E.g. Visual Studio.

change your tooling? :)

[rjgotten]

change your tooling? :)

You're right. We should all ditch NPM as a package manager and look for a better alternative...

[isdzulqor]

I got this error too when want to install npm install html-webpack-plugin --save-dev

npm install --no-optional not working. I am using npm version 3.10.3. any solution guys?
thank you

[glen-84]

@isdzulqor You can ignore the warnings. This issue is about changing the log level from WARN to INFO (or, better yet, DEBUG, so that they won't even show up by default).

[watilde]

I opened PR: #17530.

There is one thing I changed with the original proposal in my pull request. We have log.info for sure but it doesn't display INFO anymore, so I replaced info with notice.

[jods4]

BTW Yarn just fixed this. In their next release this "warning" will be info.
Meanwhile, npm still doesn't care -- even closes the issue -- although it's their top voted issue.

If you can you should switch from NPM to Yarn, it's better in pretty much every regard: speed, determinist install, offline mode, lock file by default, yarn run local packages (yeah -- just released npx, too late for me).

[akvadrako]

This issue should be reopened and fixed.

[mikemaccana]

Confirmed this is fixed in yarn 1.0.1:

info fsevents@1.1.2: The platform "linux" is incompatible with this module.
info "fsevents@1.1.2" is an optional dependency and failed compatibility check. Excluding it from installation.

[whitneyland]

BTW Yarn just fixed this. In their next release this "warning" will be info.
Meanwhile, npm still doesn't care -- even closes the issue -- although it's their top voted issue.

If you can you should switch from NPM to Yarn, it's better in pretty much every regard: speed,
determinist install, offline mode, lock file by default, yarn run local packages (yeah -- just released npx,
too late for me).

@jods4 Interesting response from the NPM team, considering that community feedback is such a powerful tool to maintain momentum of success. Proactively responding to feedback is usually required to prevent projects from slowly losing relevance, or even eventually failing.

I’ll tell you this, I may have projects that fail, but if they do I guarantee it will never happen for some straightforward issue that is being held up in front of my face by the community.

Btw, thanks for the yarn recommendation. It seems to work great as a drop in replacement with no hassles.

[mborysenko]

Today have updated the npm till the 5.6.0 version and now I'm getting ERR instead of WARN while installing the react-redux package. Some of the dependencies in my project have a dependency on a chokidar. Before I could just ignore that warning but now my builds are failing. --no-optional parameter doesn't help

D:\dev\styles-demo>npm install react-redux@latest --save --no-optional
npm ERR! code EBADPLATFORM
npm ERR! notsup Unsupported platform for fsevents@1.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})
npm ERR! notsup Valid OS:    darwin
npm ERR! notsup Valid Arch:  any
npm ERR! notsup Actual OS:   win32
npm ERR! notsup Actual Arch: x64

Question: why npm tries to install something that is considered as optional(is installed in defined conditions) or should be installed on a certain platform? Shouldn't it skip it if does not meet conditions?

[mborysenko]

D:\projects\styles-demo>npm install react-redux@latest --save
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.0.0 (node_modules\browser-sync\node_modules\chokidar\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.0.0 (node_modules\webpack\node_modules\chokidar\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.0.0 (node_modules\webpack-dev-server\node_modules\chokidar\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@^1.0.0 (node_modules\webpack-env\node_modules\chokidar\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})

Message when npm of version 5.5.1 is used

[gaearon]

It's probably better to file a separate bug report for this.
Maintainers typically don't read closed issues.

[YasharF]

New PR: #19198

[shane-reaume]

@gaearon So this was fixed? I still get errors so maybe we should re-open?

[jeffvandyke]

Yes, this absolutely should be re-opened. It's labeled and clear, PR #19198 is not merged yet, this issue is clear, and Linux and Windows people have been seeing that wretched npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents... for years now whenever at least webpack is installed. Still semi-optimistic for a WARN-free npm install on popular projects though...

[YasharF]

In case if anyone is looking for the current state of the issue and haven't had a chance to read all of the related GitHub issues and pull requests, here is a summary:

The current "open" ticket for this problem seems to be: #17466
The current PR for resolving this is: #19198

Historically from what I gathered:

• This was initially brought up in Issue npm@3 should not be trying to install modules that arch/os say are incompatible #8921
• Issue 8921 was closed and then the problem resurfaced and a new GitHub issue was opened for it: Issue npm@3.5.0 should not be trying to install modules that arch/os say are incompatible #10768
• The discussions in Issue 10768 resulted in its replacement with this ticket (aka Issue Info, rather than Warn, when skipping packages not suitable to target OS #11632) to capture the actionable item.
• PR install: log failed optional dependencies as info instead of warn (fixes #11632) #12841 was created by a community member to address Issue 11632, but the feedback from the maintainers asked for changes (install: log failed optional dependencies as info instead of warn (fixes #11632) #12841 (comment)) to the PR.
• PR install: use log.info for incompatible optional deps #17530 was created by another community member to address the feedback by the maintainers in the prior PR. More changes were requested by the maintainers, however the PR was closed by the submitter.
• There was no response on this ticket (Issue Info, rather than Warn, when skipping packages not suitable to target OS #11632) for a while which resulted in it being autoclosed by a bot. This resulted in creation of two new GitHub issues by the community, one to ask for this ticket to be reopened (Issue Please Re-Open https://github.com/npm/npm/issues/11632 #17500), and the other to replace this request: Issue "npm install" should not warn about failed optional dependencies which are not relevant for my os/architecture #17466
• PR Log failed optional platform dependencies as info. #19198 was submitted to address the feedback by the maintainers for the prior PRs.

I know this history list is long and perhaps a sign that some process improvement may be needed, but this is where we are now. Again:

The current "open" ticket for this problem seems to be: #17466
The current PR for resolving this is: #19198

[vandyw95]

Y'all gonna face a problem in the future if y'all ignore the "WARN".
Please read it here #19198 as how this impact my company apps and of course wasting my time to refactor that done nothing good to fix the bug.
WARN works as it does. It doesn't mean that if your app is fine you can just ignore. It is NOT no problem but it IS a problem but you just don't know it yet because it hasn't happened yet.

[vandyw95]

@YasharF -1 for any reason?
Is it wrong if it "WARN"? Because I got more trouble by looking at it only as a (read: ignore) "WARN" not "ERROR", and lower it to "INFO" rather than "WARN"?

[YasharF]

@vandyw95 you haven't read the discussions and commenting on a closed github issue.

[vandyw95]

@YasharF discussions which point to this one in conclusion >> remove the word 'failed' and use 'INFO' instead of 'WARN'
And this the reason of my comment about changing "WARN" to "INFO".
And I had read the discussions. If commenting here is wrong why don't you point out your thought here? :)