Log failed optional platform dependencies as info

[cmedinasoriano]

The intention of this PR is to continue the discussion on npm/npm#19198
All credits to this fix goes to @jacksonrayhamilton
My only contribution was to apply the same fixes to current npm/cli and opening the discussion again.

This was the PR message for npm/npm#19198 (with corrected issue refs to npm/npm):
Fixesnpm/npm#11632, reducing the log level of nonfatal errors when installing optional dependencies on an unsupported platform (e.g. fsevents on GNU/Linux). Adapts the changes from npm/npm#12841 to the current state of the repo and endeavors to implement the requested changes in this issue comment.

In the last two PRs that attempted to address this, it was suggested a "debug" error level be used, but it does not seem like "debug" exists as an error level in npmlog. "info" seems to have similar intent though, and it does eliminate the message by default:

~/projects/chokidar-test λ cat package.json {
"dependencies": {
"chokidar": "^1.7.0"
}
}
~/projects/chokidar-test λ npm i
npm WARN chokidar-test No description
npm WARN chokidar-test No repository field.
npm WARN chokidar-test No license field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.1.3 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
added 116 packages in 4.831s
~/projects/chokidar-test λ ../npm/bin/npm-cli.js i
npm WARN chokidar-test No description
npm WARN chokidar-test No repository field.
npm WARN chokidar-test No license field.
added 116 packages in 4.122s

[13rac1]

@zkat I suggest not labeling this needs-discussion. This issue has already been bikeshed for years. Originally starting four years ago in npm/npm#8921 with a detailed summary in npm/npm#11632 (comment)

[aeschright]

We use needs-discussion to flag that the team may need to make an internal decision or coordinate with other parts of the organization. In this case, because the change is marked semver-major, the soonest it can be merged will be the npm 7 release in a few months.

[Allactaga]

@aeschright, I am not familiar with the internal processes of the team. Can you please share when the discussion will take place? Will you make sure that this change will go out with npm7 and we don't have to wait for npm8?

[herebebeasties]

@aeschright / @zkat: Why does omitting a log message like this count as public API surface area worthy of a major semver update?

Given that the community clearly would like it fixed (literally hundreds of comments/votes across multiple issues) and that the actual substantial change here is a totally trivial three line patch, that it's so far taken more than four years to look at this given all the activity and comments around it is frankly mind-boggling. It massively puts people off contributing to the project. I certainly wouldn't bother, looking at how all this has been handled. 👎

[jacksonrayhamilton]

@herebebeasties Exactly. You hit the nail on the head. Let NPM burn! 🔥 🔥

@cmedinasoriano, I implore you to close this PR. Let’s let NPM fail. Let’s tell our friends to switch to Yarn because NPM is a poorly-run project.

[jacksonrayhamilton]

NPM can either improve, or die. It may have been a mistake for Node to include this company’s CLI in the Node installation. The company can prove to us whether that’s the case or not. If we will sentiment to change, then a better package manager, or least better stewardship, could be available to us in the future.

[ljharb]

That’s a pretty strong reaction to a PR about a log message.

Speaking as a maintainer myself, the age of an issue does not have any correlation whatsoever to its priority, its risks, or the speed of addressing it.

[jacksonrayhamilton]

I dedicated several hours of my time to learn how the project worked, and in more than one instance provided code and tests, all free of charge. How many people pause their lives to do that?

The first time I did that, they missed my contribution and commented months later that it’d been fixed elsewhere. The second time, I advocated for my change for months, only to see the issue closed by a bot. Scroll through the hundreds of comments and reactions over the past years in relation to this “pitiful, insignificant” log message update to gauge why NPM is truly a poorly-run project.

And at the end of all of it, I get to read snarky comments like yours, implying that I should sit down and shut up. Nope, no more of that.

[ljharb]

I’m not being snarky; but while it’s commendable for you to donate your time and effort, that in no way obligates anyone else to do so, including npm.

[jacksonrayhamilton]

Actually, it does. It’s a rather fundamental concept we humans have of a fair exchange of value.

[ljharb]

No, that concept requires previous agreement. You can’t obligate someone to do work for you just because you decided to do work for them of your own accord, without their cooperation or remuneration or agreement.

What you’re describing is called entitlement, not a fair exchange.

[herebebeasties]

@ljharb

Speaking as a maintainer myself, the age of an issue does not have any correlation whatsoever to its priority, its risks, or the speed of addressing it.

No, quite right. I didn't say it did.
However, I did spell out the low risk of addressing this, the low time impact of reviewing it and the large number of people in the NPM community who are asking for it to be fixed.

When an issue that is literally a trivial three line fix and that has hundreds of people clamouring for you to land the community-provided (!) PR for it, is ignored entirely for four years, and maintainers are spending longer fending off people who are complaining about it rather than just landing the bloody thing, you surely have to concede that you are doing something wrong.

You can trot out the "it's free, you have no right to complain" line if you want to, but you are seriously losing mindshare and goodwill from a community that has already provided a fix for this for you, not once, but about four times over, and just been ignored and ignored for years.

It does not help your cause to then complain at these same people who have provided a fix. It's toxic behaviour and rightly makes them feel pissed.

[herebebeasties]

What you’re describing is called entitlement, not a fair exchange.

Actually, what he is describing is how healthy open source projects work.

I think we would all appreciate it if you could avoid using such personal terminology as "entitlement" (which to me seems totally unwarranted in this case - he provided the patch, which is pretty much the opposite) and concentrated on the actual issue here, which is getting this thing fixed.

In half the time spent antagonising each other on this issue, it could easily have been reviewed and landed.

[ljharb]

@herebebeasties my comment wasn’t directed at you; and the health of an open source project is not generically measured by how fast PRs are merged, nor which are merged. I understand their frustration, but “let npm burn” is not a productive or warranted sentiment to express.

Note; I’m not a maintainer here - there aren’t maintainers “fending off” anyone. I’m just a maintainer of other projects responding to the unjustified vitriol, even if it comes from understandable frustration.

[aeschright]

Unfortunately, since we were let go from npm there's not much I can do about whether this PR gets merged or released. It's very difficult to make progress when there are no resources. I know this has been frustrating for cli users and contributors, but please be aware that the developers who've worked on this project have no control over what the company is doing now.

[jacksonrayhamilton]

I understand their frustration, but “let npm burn” is not a productive or warranted sentiment to express.

What doesn’t kill them can make them stronger. Otherwise, space can be made for a new default package manager for Node, or space can be made for new management for the NPM CLI that ships with Node. As a community we shouldn’t be complacent with the current state of affairs.

I can certainly sympathize with the predicament @aeschright describes. Responsibility travels up to NPM’s management and owners for prioritizing open source work. Are they up to that task? If not, NPM users should take their business elsewhere.

[icavalheiro]

Please merge this T-T
Those fsevents warning have been haunting me for years now, on my windows and linux work machines!

[tomcanham]

Ditto on "please merge" -- I try to get clean builds, and the warning (for fsevents in my case) is annoying.

[emmaffiondavies]

BUMP! This is getting ridiculous, I want my clean build damnit 😢 The best workaround I've found so far is as follows, but it's limited in that it means if you have genuine optional dependencies in your project, then they'll always be ignored (works fine for me as I don't have any):

package.json:

{
"optionalDependencies": {
"fsevents": "*"
}
}

Install with:
npm install --no-optional

[NishealJ]

is this expected to fix npm/npm#18712 ?

[spaceneenja]

It baffles me to think of the literal days which humanity has collectively spent on this issue. Something that seems to be easily fixed with a few lines of code. How many questions, GitHub issues, pull requests, google searches, etc... that this has caused?

NPM is a powerful tool but increasingly it's looking like it's the wrong package manager to be automatically included with Node. There are alternatives which take developer experience more seriously and don't offer up blase responses to concerns provided by the community.

[jacksonrayhamilton]

NPM is a powerful tool but increasingly it's looking like it's the wrong package manager to be automatically included with Node.

Yep. Maybe Node’s maintainers should fork the CLI.

Since people expect an npm program to be installed it might be tricky to replace NPM with Yarn or pnpm; there would have to be a compatibility layer that would turn npm install into a yarn install, convert between lockfile formats, etc.

[ljharb]

A lot of work has been put into npm 7 to resolve the many complex (not trivial) issues with optional deps and logging; just because this PR hasn’t seen movement doesn’t mean the problem is being ignored.

Nothing about FOSS guarantees any PR will be accepted; i think your expectations are set incorrectly.

[darcyclarke]

@cmedinasoriano sorry for the delay here. I'm closing this as we don't print optional dep info/warnings today in v7 & the original issue referenced has also been closed. Appreciate the contribution though.

[markuszeller]

Warnings should be reduced to a minimum and only be given on a non-optional dependency. Seeing always so many warnings attracts unneeded attention.

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.1.2 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.1.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/webpack-dev-server/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/watchpack-chokidar2/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

[karikera]

I don't know why should I be warned even using normal working modules.

[JavierLight]

Does the npm dev team ever heard of the concept "normalization of deviance"?

This should never appear as a warning!!

[Pointotech]

I switched to Yarn on all of my projects because of the ridiculous dysfunction that this thread demonstrates. Haven't seen an fsevents warning since :)

[bibipkins]

its been 2 years since I last visited this thread. still not fixed and I still have to see this garbage in my build logs...

[cmedinasoriano]

The intention of this PR is to continue the discussion on npm/npm#19198
All credits to this fix goes to @jacksonrayhamilton
My only contribution was to apply the same fixes to current npm/cli and opening the discussion again.

This was the PR message for npm/npm#19198 (with corrected issue refs to npm/npm):
Fixesnpm/npm#11632, reducing the log level of nonfatal errors when installing optional dependencies on an unsupported platform (e.g. fsevents on GNU/Linux). Adapts the changes from npm/npm#12841 to the current state of the repo and endeavors to implement the requested changes in this issue comment.

In the last two PRs that attempted to address this, it was suggested a "debug" error level be used, but it does not seem like "debug" exists as an error level in npmlog. "info" seems to have similar intent though, and it does eliminate the message by default:

~/projects/chokidar-test λ cat package.json {
"dependencies": {
"chokidar": "^1.7.0"
}
}
~/projects/chokidar-test λ npm i
npm WARN chokidar-test No description
npm WARN chokidar-test No repository field.
npm WARN chokidar-test No license field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.1.3 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
added 116 packages in 4.831s
~/projects/chokidar-test λ ../npm/bin/npm-cli.js i
npm WARN chokidar-test No description
npm WARN chokidar-test No repository field.
npm WARN chokidar-test No license field.
added 116 packages in 4.122s

[13rac1]

@zkat I suggest not labeling this needs-discussion. This issue has already been bikeshed for years. Originally starting four years ago in npm/npm#8921 with a detailed summary in npm/npm#11632 (comment)

[aeschright]

We use needs-discussion to flag that the team may need to make an internal decision or coordinate with other parts of the organization. In this case, because the change is marked semver-major, the soonest it can be merged will be the npm 7 release in a few months.

[Allactaga]

@aeschright, I am not familiar with the internal processes of the team. Can you please share when the discussion will take place? Will you make sure that this change will go out with npm7 and we don't have to wait for npm8?

[herebebeasties]

@aeschright / @zkat: Why does omitting a log message like this count as public API surface area worthy of a major semver update?

Given that the community clearly would like it fixed (literally hundreds of comments/votes across multiple issues) and that the actual substantial change here is a totally trivial three line patch, that it's so far taken more than four years to look at this given all the activity and comments around it is frankly mind-boggling. It massively puts people off contributing to the project. I certainly wouldn't bother, looking at how all this has been handled. 👎

[jacksonrayhamilton]

@herebebeasties Exactly. You hit the nail on the head. Let NPM burn! 🔥 🔥

@cmedinasoriano, I implore you to close this PR. Let’s let NPM fail. Let’s tell our friends to switch to Yarn because NPM is a poorly-run project.

[jacksonrayhamilton]

NPM can either improve, or die. It may have been a mistake for Node to include this company’s CLI in the Node installation. The company can prove to us whether that’s the case or not. If we will sentiment to change, then a better package manager, or least better stewardship, could be available to us in the future.

[ljharb]

That’s a pretty strong reaction to a PR about a log message.

Speaking as a maintainer myself, the age of an issue does not have any correlation whatsoever to its priority, its risks, or the speed of addressing it.

[jacksonrayhamilton]

I dedicated several hours of my time to learn how the project worked, and in more than one instance provided code and tests, all free of charge. How many people pause their lives to do that?

The first time I did that, they missed my contribution and commented months later that it’d been fixed elsewhere. The second time, I advocated for my change for months, only to see the issue closed by a bot. Scroll through the hundreds of comments and reactions over the past years in relation to this “pitiful, insignificant” log message update to gauge why NPM is truly a poorly-run project.

And at the end of all of it, I get to read snarky comments like yours, implying that I should sit down and shut up. Nope, no more of that.

[ljharb]

I’m not being snarky; but while it’s commendable for you to donate your time and effort, that in no way obligates anyone else to do so, including npm.

[jacksonrayhamilton]

Actually, it does. It’s a rather fundamental concept we humans have of a fair exchange of value.

[ljharb]

No, that concept requires previous agreement. You can’t obligate someone to do work for you just because you decided to do work for them of your own accord, without their cooperation or remuneration or agreement.

What you’re describing is called entitlement, not a fair exchange.

[herebebeasties]

@ljharb

Speaking as a maintainer myself, the age of an issue does not have any correlation whatsoever to its priority, its risks, or the speed of addressing it.

No, quite right. I didn't say it did.
However, I did spell out the low risk of addressing this, the low time impact of reviewing it and the large number of people in the NPM community who are asking for it to be fixed.

When an issue that is literally a trivial three line fix and that has hundreds of people clamouring for you to land the community-provided (!) PR for it, is ignored entirely for four years, and maintainers are spending longer fending off people who are complaining about it rather than just landing the bloody thing, you surely have to concede that you are doing something wrong.

You can trot out the "it's free, you have no right to complain" line if you want to, but you are seriously losing mindshare and goodwill from a community that has already provided a fix for this for you, not once, but about four times over, and just been ignored and ignored for years.

It does not help your cause to then complain at these same people who have provided a fix. It's toxic behaviour and rightly makes them feel pissed.

[herebebeasties]

What you’re describing is called entitlement, not a fair exchange.

Actually, what he is describing is how healthy open source projects work.

I think we would all appreciate it if you could avoid using such personal terminology as "entitlement" (which to me seems totally unwarranted in this case - he provided the patch, which is pretty much the opposite) and concentrated on the actual issue here, which is getting this thing fixed.

In half the time spent antagonising each other on this issue, it could easily have been reviewed and landed.

[ljharb]

@herebebeasties my comment wasn’t directed at you; and the health of an open source project is not generically measured by how fast PRs are merged, nor which are merged. I understand their frustration, but “let npm burn” is not a productive or warranted sentiment to express.

Note; I’m not a maintainer here - there aren’t maintainers “fending off” anyone. I’m just a maintainer of other projects responding to the unjustified vitriol, even if it comes from understandable frustration.

[aeschright]

Unfortunately, since we were let go from npm there's not much I can do about whether this PR gets merged or released. It's very difficult to make progress when there are no resources. I know this has been frustrating for cli users and contributors, but please be aware that the developers who've worked on this project have no control over what the company is doing now.

[jacksonrayhamilton]

I understand their frustration, but “let npm burn” is not a productive or warranted sentiment to express.

What doesn’t kill them can make them stronger. Otherwise, space can be made for a new default package manager for Node, or space can be made for new management for the NPM CLI that ships with Node. As a community we shouldn’t be complacent with the current state of affairs.

I can certainly sympathize with the predicament @aeschright describes. Responsibility travels up to NPM’s management and owners for prioritizing open source work. Are they up to that task? If not, NPM users should take their business elsewhere.

[icavalheiro]

Please merge this T-T
Those fsevents warning have been haunting me for years now, on my windows and linux work machines!

[tomcanham]

Ditto on "please merge" -- I try to get clean builds, and the warning (for fsevents in my case) is annoying.

[emmaffiondavies]

BUMP! This is getting ridiculous, I want my clean build damnit 😢 The best workaround I've found so far is as follows, but it's limited in that it means if you have genuine optional dependencies in your project, then they'll always be ignored (works fine for me as I don't have any):

package.json:

{
"optionalDependencies": {
"fsevents": "*"
}
}

Install with:
npm install --no-optional

[NishealJ]

is this expected to fix npm/npm#18712 ?

[spaceneenja]

It baffles me to think of the literal days which humanity has collectively spent on this issue. Something that seems to be easily fixed with a few lines of code. How many questions, GitHub issues, pull requests, google searches, etc... that this has caused?

NPM is a powerful tool but increasingly it's looking like it's the wrong package manager to be automatically included with Node. There are alternatives which take developer experience more seriously and don't offer up blase responses to concerns provided by the community.

[jacksonrayhamilton]

NPM is a powerful tool but increasingly it's looking like it's the wrong package manager to be automatically included with Node.

Yep. Maybe Node’s maintainers should fork the CLI.

Since people expect an npm program to be installed it might be tricky to replace NPM with Yarn or pnpm; there would have to be a compatibility layer that would turn npm install into a yarn install, convert between lockfile formats, etc.

[ljharb]

A lot of work has been put into npm 7 to resolve the many complex (not trivial) issues with optional deps and logging; just because this PR hasn’t seen movement doesn’t mean the problem is being ignored.

Nothing about FOSS guarantees any PR will be accepted; i think your expectations are set incorrectly.

[darcyclarke]

@cmedinasoriano sorry for the delay here. I'm closing this as we don't print optional dep info/warnings today in v7 & the original issue referenced has also been closed. Appreciate the contribution though.

[markuszeller]

Warnings should be reduced to a minimum and only be given on a non-optional dependency. Seeing always so many warnings attracts unneeded attention.

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.1.2 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.1.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/webpack-dev-server/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/watchpack-chokidar2/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

[karikera]

I don't know why should I be warned even using normal working modules.

[JavierLight]

Does the npm dev team ever heard of the concept "normalization of deviance"?

This should never appear as a warning!!

[Pointotech]

I switched to Yarn on all of my projects because of the ridiculous dysfunction that this thread demonstrates. Haven't seen an fsevents warning since :)

[bibipkins]

its been 2 years since I last visited this thread. still not fixed and I still have to see this garbage in my build logs...

[cmedinasoriano]

The intention of this PR is to continue the discussion on npm/npm#19198
All credits to this fix goes to @jacksonrayhamilton
My only contribution was to apply the same fixes to current npm/cli and opening the discussion again.

This was the PR message for npm/npm#19198 (with corrected issue refs to npm/npm):
Fixesnpm/npm#11632, reducing the log level of nonfatal errors when installing optional dependencies on an unsupported platform (e.g. fsevents on GNU/Linux). Adapts the changes from npm/npm#12841 to the current state of the repo and endeavors to implement the requested changes in this issue comment.

In the last two PRs that attempted to address this, it was suggested a "debug" error level be used, but it does not seem like "debug" exists as an error level in npmlog. "info" seems to have similar intent though, and it does eliminate the message by default:

~/projects/chokidar-test λ cat package.json {
"dependencies": {
"chokidar": "^1.7.0"
}
}
~/projects/chokidar-test λ npm i
npm WARN chokidar-test No description
npm WARN chokidar-test No repository field.
npm WARN chokidar-test No license field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.1.3 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
added 116 packages in 4.831s
~/projects/chokidar-test λ ../npm/bin/npm-cli.js i
npm WARN chokidar-test No description
npm WARN chokidar-test No repository field.
npm WARN chokidar-test No license field.
added 116 packages in 4.122s

[13rac1]

@zkat I suggest not labeling this needs-discussion. This issue has already been bikeshed for years. Originally starting four years ago in npm/npm#8921 with a detailed summary in npm/npm#11632 (comment)

[aeschright]

We use needs-discussion to flag that the team may need to make an internal decision or coordinate with other parts of the organization. In this case, because the change is marked semver-major, the soonest it can be merged will be the npm 7 release in a few months.

[Allactaga]

@aeschright, I am not familiar with the internal processes of the team. Can you please share when the discussion will take place? Will you make sure that this change will go out with npm7 and we don't have to wait for npm8?

[herebebeasties]

@aeschright / @zkat: Why does omitting a log message like this count as public API surface area worthy of a major semver update?

Given that the community clearly would like it fixed (literally hundreds of comments/votes across multiple issues) and that the actual substantial change here is a totally trivial three line patch, that it's so far taken more than four years to look at this given all the activity and comments around it is frankly mind-boggling. It massively puts people off contributing to the project. I certainly wouldn't bother, looking at how all this has been handled. 👎

[jacksonrayhamilton]

@herebebeasties Exactly. You hit the nail on the head. Let NPM burn! 🔥 🔥

@cmedinasoriano, I implore you to close this PR. Let’s let NPM fail. Let’s tell our friends to switch to Yarn because NPM is a poorly-run project.

[jacksonrayhamilton]

NPM can either improve, or die. It may have been a mistake for Node to include this company’s CLI in the Node installation. The company can prove to us whether that’s the case or not. If we will sentiment to change, then a better package manager, or least better stewardship, could be available to us in the future.

[ljharb]

That’s a pretty strong reaction to a PR about a log message.

Speaking as a maintainer myself, the age of an issue does not have any correlation whatsoever to its priority, its risks, or the speed of addressing it.

[jacksonrayhamilton]

I dedicated several hours of my time to learn how the project worked, and in more than one instance provided code and tests, all free of charge. How many people pause their lives to do that?

The first time I did that, they missed my contribution and commented months later that it’d been fixed elsewhere. The second time, I advocated for my change for months, only to see the issue closed by a bot. Scroll through the hundreds of comments and reactions over the past years in relation to this “pitiful, insignificant” log message update to gauge why NPM is truly a poorly-run project.

And at the end of all of it, I get to read snarky comments like yours, implying that I should sit down and shut up. Nope, no more of that.

[ljharb]

I’m not being snarky; but while it’s commendable for you to donate your time and effort, that in no way obligates anyone else to do so, including npm.

[jacksonrayhamilton]

Actually, it does. It’s a rather fundamental concept we humans have of a fair exchange of value.

[ljharb]

No, that concept requires previous agreement. You can’t obligate someone to do work for you just because you decided to do work for them of your own accord, without their cooperation or remuneration or agreement.

What you’re describing is called entitlement, not a fair exchange.

[herebebeasties]

@ljharb

Speaking as a maintainer myself, the age of an issue does not have any correlation whatsoever to its priority, its risks, or the speed of addressing it.

No, quite right. I didn't say it did.
However, I did spell out the low risk of addressing this, the low time impact of reviewing it and the large number of people in the NPM community who are asking for it to be fixed.

When an issue that is literally a trivial three line fix and that has hundreds of people clamouring for you to land the community-provided (!) PR for it, is ignored entirely for four years, and maintainers are spending longer fending off people who are complaining about it rather than just landing the bloody thing, you surely have to concede that you are doing something wrong.

You can trot out the "it's free, you have no right to complain" line if you want to, but you are seriously losing mindshare and goodwill from a community that has already provided a fix for this for you, not once, but about four times over, and just been ignored and ignored for years.

It does not help your cause to then complain at these same people who have provided a fix. It's toxic behaviour and rightly makes them feel pissed.

[herebebeasties]

What you’re describing is called entitlement, not a fair exchange.

Actually, what he is describing is how healthy open source projects work.

I think we would all appreciate it if you could avoid using such personal terminology as "entitlement" (which to me seems totally unwarranted in this case - he provided the patch, which is pretty much the opposite) and concentrated on the actual issue here, which is getting this thing fixed.

In half the time spent antagonising each other on this issue, it could easily have been reviewed and landed.

[ljharb]

@herebebeasties my comment wasn’t directed at you; and the health of an open source project is not generically measured by how fast PRs are merged, nor which are merged. I understand their frustration, but “let npm burn” is not a productive or warranted sentiment to express.

Note; I’m not a maintainer here - there aren’t maintainers “fending off” anyone. I’m just a maintainer of other projects responding to the unjustified vitriol, even if it comes from understandable frustration.

[aeschright]

Unfortunately, since we were let go from npm there's not much I can do about whether this PR gets merged or released. It's very difficult to make progress when there are no resources. I know this has been frustrating for cli users and contributors, but please be aware that the developers who've worked on this project have no control over what the company is doing now.

[jacksonrayhamilton]

I understand their frustration, but “let npm burn” is not a productive or warranted sentiment to express.

What doesn’t kill them can make them stronger. Otherwise, space can be made for a new default package manager for Node, or space can be made for new management for the NPM CLI that ships with Node. As a community we shouldn’t be complacent with the current state of affairs.

I can certainly sympathize with the predicament @aeschright describes. Responsibility travels up to NPM’s management and owners for prioritizing open source work. Are they up to that task? If not, NPM users should take their business elsewhere.

[icavalheiro]

Please merge this T-T
Those fsevents warning have been haunting me for years now, on my windows and linux work machines!

[tomcanham]

Ditto on "please merge" -- I try to get clean builds, and the warning (for fsevents in my case) is annoying.

[emmaffiondavies]

BUMP! This is getting ridiculous, I want my clean build damnit 😢 The best workaround I've found so far is as follows, but it's limited in that it means if you have genuine optional dependencies in your project, then they'll always be ignored (works fine for me as I don't have any):

package.json:

{
"optionalDependencies": {
"fsevents": "*"
}
}

Install with:
npm install --no-optional

[NishealJ]

is this expected to fix npm/npm#18712 ?

[spaceneenja]

It baffles me to think of the literal days which humanity has collectively spent on this issue. Something that seems to be easily fixed with a few lines of code. How many questions, GitHub issues, pull requests, google searches, etc... that this has caused?

NPM is a powerful tool but increasingly it's looking like it's the wrong package manager to be automatically included with Node. There are alternatives which take developer experience more seriously and don't offer up blase responses to concerns provided by the community.

[jacksonrayhamilton]

NPM is a powerful tool but increasingly it's looking like it's the wrong package manager to be automatically included with Node.

Yep. Maybe Node’s maintainers should fork the CLI.

Since people expect an npm program to be installed it might be tricky to replace NPM with Yarn or pnpm; there would have to be a compatibility layer that would turn npm install into a yarn install, convert between lockfile formats, etc.

[ljharb]

A lot of work has been put into npm 7 to resolve the many complex (not trivial) issues with optional deps and logging; just because this PR hasn’t seen movement doesn’t mean the problem is being ignored.

Nothing about FOSS guarantees any PR will be accepted; i think your expectations are set incorrectly.

[darcyclarke]

@cmedinasoriano sorry for the delay here. I'm closing this as we don't print optional dep info/warnings today in v7 & the original issue referenced has also been closed. Appreciate the contribution though.

[markuszeller]

Warnings should be reduced to a minimum and only be given on a non-optional dependency. Seeing always so many warnings attracts unneeded attention.

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.1.2 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.1.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/webpack-dev-server/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/watchpack-chokidar2/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

[karikera]

I don't know why should I be warned even using normal working modules.

[JavierLight]

Does the npm dev team ever heard of the concept "normalization of deviance"?

This should never appear as a warning!!

[Pointotech]

I switched to Yarn on all of my projects because of the ridiculous dysfunction that this thread demonstrates. Haven't seen an fsevents warning since :)

[bibipkins]

its been 2 years since I last visited this thread. still not fixed and I still have to see this garbage in my build logs...

[cmedinasoriano]

The intention of this PR is to continue the discussion on npm/npm#19198
All credits to this fix goes to @jacksonrayhamilton
My only contribution was to apply the same fixes to current npm/cli and opening the discussion again.

This was the PR message for npm/npm#19198 (with corrected issue refs to npm/npm):
Fixesnpm/npm#11632, reducing the log level of nonfatal errors when installing optional dependencies on an unsupported platform (e.g. fsevents on GNU/Linux). Adapts the changes from npm/npm#12841 to the current state of the repo and endeavors to implement the requested changes in this issue comment.

In the last two PRs that attempted to address this, it was suggested a "debug" error level be used, but it does not seem like "debug" exists as an error level in npmlog. "info" seems to have similar intent though, and it does eliminate the message by default:

~/projects/chokidar-test λ cat package.json {
"dependencies": {
"chokidar": "^1.7.0"
}
}
~/projects/chokidar-test λ npm i
npm WARN chokidar-test No description
npm WARN chokidar-test No repository field.
npm WARN chokidar-test No license field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.1.3 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
added 116 packages in 4.831s
~/projects/chokidar-test λ ../npm/bin/npm-cli.js i
npm WARN chokidar-test No description
npm WARN chokidar-test No repository field.
npm WARN chokidar-test No license field.
added 116 packages in 4.122s

[13rac1]

@zkat I suggest not labeling this needs-discussion. This issue has already been bikeshed for years. Originally starting four years ago in npm/npm#8921 with a detailed summary in npm/npm#11632 (comment)

[aeschright]

We use needs-discussion to flag that the team may need to make an internal decision or coordinate with other parts of the organization. In this case, because the change is marked semver-major, the soonest it can be merged will be the npm 7 release in a few months.

[Allactaga]

@aeschright, I am not familiar with the internal processes of the team. Can you please share when the discussion will take place? Will you make sure that this change will go out with npm7 and we don't have to wait for npm8?

[herebebeasties]

@aeschright / @zkat: Why does omitting a log message like this count as public API surface area worthy of a major semver update?

Given that the community clearly would like it fixed (literally hundreds of comments/votes across multiple issues) and that the actual substantial change here is a totally trivial three line patch, that it's so far taken more than four years to look at this given all the activity and comments around it is frankly mind-boggling. It massively puts people off contributing to the project. I certainly wouldn't bother, looking at how all this has been handled. 👎

[jacksonrayhamilton]

@herebebeasties Exactly. You hit the nail on the head. Let NPM burn! 🔥 🔥

@cmedinasoriano, I implore you to close this PR. Let’s let NPM fail. Let’s tell our friends to switch to Yarn because NPM is a poorly-run project.

[jacksonrayhamilton]

NPM can either improve, or die. It may have been a mistake for Node to include this company’s CLI in the Node installation. The company can prove to us whether that’s the case or not. If we will sentiment to change, then a better package manager, or least better stewardship, could be available to us in the future.

[ljharb]

That’s a pretty strong reaction to a PR about a log message.

Speaking as a maintainer myself, the age of an issue does not have any correlation whatsoever to its priority, its risks, or the speed of addressing it.

[jacksonrayhamilton]

I dedicated several hours of my time to learn how the project worked, and in more than one instance provided code and tests, all free of charge. How many people pause their lives to do that?

The first time I did that, they missed my contribution and commented months later that it’d been fixed elsewhere. The second time, I advocated for my change for months, only to see the issue closed by a bot. Scroll through the hundreds of comments and reactions over the past years in relation to this “pitiful, insignificant” log message update to gauge why NPM is truly a poorly-run project.

And at the end of all of it, I get to read snarky comments like yours, implying that I should sit down and shut up. Nope, no more of that.

[ljharb]

I’m not being snarky; but while it’s commendable for you to donate your time and effort, that in no way obligates anyone else to do so, including npm.

[jacksonrayhamilton]

Actually, it does. It’s a rather fundamental concept we humans have of a fair exchange of value.

[ljharb]

No, that concept requires previous agreement. You can’t obligate someone to do work for you just because you decided to do work for them of your own accord, without their cooperation or remuneration or agreement.

What you’re describing is called entitlement, not a fair exchange.

[herebebeasties]

@ljharb

Speaking as a maintainer myself, the age of an issue does not have any correlation whatsoever to its priority, its risks, or the speed of addressing it.

No, quite right. I didn't say it did.
However, I did spell out the low risk of addressing this, the low time impact of reviewing it and the large number of people in the NPM community who are asking for it to be fixed.

When an issue that is literally a trivial three line fix and that has hundreds of people clamouring for you to land the community-provided (!) PR for it, is ignored entirely for four years, and maintainers are spending longer fending off people who are complaining about it rather than just landing the bloody thing, you surely have to concede that you are doing something wrong.

You can trot out the "it's free, you have no right to complain" line if you want to, but you are seriously losing mindshare and goodwill from a community that has already provided a fix for this for you, not once, but about four times over, and just been ignored and ignored for years.

It does not help your cause to then complain at these same people who have provided a fix. It's toxic behaviour and rightly makes them feel pissed.

[herebebeasties]

What you’re describing is called entitlement, not a fair exchange.

Actually, what he is describing is how healthy open source projects work.

I think we would all appreciate it if you could avoid using such personal terminology as "entitlement" (which to me seems totally unwarranted in this case - he provided the patch, which is pretty much the opposite) and concentrated on the actual issue here, which is getting this thing fixed.

In half the time spent antagonising each other on this issue, it could easily have been reviewed and landed.

[ljharb]

@herebebeasties my comment wasn’t directed at you; and the health of an open source project is not generically measured by how fast PRs are merged, nor which are merged. I understand their frustration, but “let npm burn” is not a productive or warranted sentiment to express.

Note; I’m not a maintainer here - there aren’t maintainers “fending off” anyone. I’m just a maintainer of other projects responding to the unjustified vitriol, even if it comes from understandable frustration.

[aeschright]

Unfortunately, since we were let go from npm there's not much I can do about whether this PR gets merged or released. It's very difficult to make progress when there are no resources. I know this has been frustrating for cli users and contributors, but please be aware that the developers who've worked on this project have no control over what the company is doing now.

[jacksonrayhamilton]

I understand their frustration, but “let npm burn” is not a productive or warranted sentiment to express.

What doesn’t kill them can make them stronger. Otherwise, space can be made for a new default package manager for Node, or space can be made for new management for the NPM CLI that ships with Node. As a community we shouldn’t be complacent with the current state of affairs.

I can certainly sympathize with the predicament @aeschright describes. Responsibility travels up to NPM’s management and owners for prioritizing open source work. Are they up to that task? If not, NPM users should take their business elsewhere.

[icavalheiro]

Please merge this T-T
Those fsevents warning have been haunting me for years now, on my windows and linux work machines!

[tomcanham]

Ditto on "please merge" -- I try to get clean builds, and the warning (for fsevents in my case) is annoying.

[emmaffiondavies]

BUMP! This is getting ridiculous, I want my clean build damnit 😢 The best workaround I've found so far is as follows, but it's limited in that it means if you have genuine optional dependencies in your project, then they'll always be ignored (works fine for me as I don't have any):

package.json:

{
"optionalDependencies": {
"fsevents": "*"
}
}

Install with:
npm install --no-optional

[NishealJ]

is this expected to fix npm/npm#18712 ?

[spaceneenja]

It baffles me to think of the literal days which humanity has collectively spent on this issue. Something that seems to be easily fixed with a few lines of code. How many questions, GitHub issues, pull requests, google searches, etc... that this has caused?

NPM is a powerful tool but increasingly it's looking like it's the wrong package manager to be automatically included with Node. There are alternatives which take developer experience more seriously and don't offer up blase responses to concerns provided by the community.

[jacksonrayhamilton]

NPM is a powerful tool but increasingly it's looking like it's the wrong package manager to be automatically included with Node.

Yep. Maybe Node’s maintainers should fork the CLI.

Since people expect an npm program to be installed it might be tricky to replace NPM with Yarn or pnpm; there would have to be a compatibility layer that would turn npm install into a yarn install, convert between lockfile formats, etc.

[ljharb]

A lot of work has been put into npm 7 to resolve the many complex (not trivial) issues with optional deps and logging; just because this PR hasn’t seen movement doesn’t mean the problem is being ignored.

Nothing about FOSS guarantees any PR will be accepted; i think your expectations are set incorrectly.

[darcyclarke]

@cmedinasoriano sorry for the delay here. I'm closing this as we don't print optional dep info/warnings today in v7 & the original issue referenced has also been closed. Appreciate the contribution though.

[markuszeller]

Warnings should be reduced to a minimum and only be given on a non-optional dependency. Seeing always so many warnings attracts unneeded attention.

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.1.2 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.1.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/webpack-dev-server/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/watchpack-chokidar2/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

[karikera]

I don't know why should I be warned even using normal working modules.

[JavierLight]

Does the npm dev team ever heard of the concept "normalization of deviance"?

This should never appear as a warning!!

[Pointotech]

I switched to Yarn on all of my projects because of the ridiculous dysfunction that this thread demonstrates. Haven't seen an fsevents warning since :)

[bibipkins]

its been 2 years since I last visited this thread. still not fixed and I still have to see this garbage in my build logs...

[cmedinasoriano]

The intention of this PR is to continue the discussion on npm/npm#19198
All credits to this fix goes to @jacksonrayhamilton
My only contribution was to apply the same fixes to current npm/cli and opening the discussion again.

This was the PR message for npm/npm#19198 (with corrected issue refs to npm/npm):
Fixesnpm/npm#11632, reducing the log level of nonfatal errors when installing optional dependencies on an unsupported platform (e.g. fsevents on GNU/Linux). Adapts the changes from npm/npm#12841 to the current state of the repo and endeavors to implement the requested changes in this issue comment.

In the last two PRs that attempted to address this, it was suggested a "debug" error level be used, but it does not seem like "debug" exists as an error level in npmlog. "info" seems to have similar intent though, and it does eliminate the message by default:

~/projects/chokidar-test λ cat package.json {
"dependencies": {
"chokidar": "^1.7.0"
}
}
~/projects/chokidar-test λ npm i
npm WARN chokidar-test No description
npm WARN chokidar-test No repository field.
npm WARN chokidar-test No license field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.1.3 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
added 116 packages in 4.831s
~/projects/chokidar-test λ ../npm/bin/npm-cli.js i
npm WARN chokidar-test No description
npm WARN chokidar-test No repository field.
npm WARN chokidar-test No license field.
added 116 packages in 4.122s

[13rac1]

@zkat I suggest not labeling this needs-discussion. This issue has already been bikeshed for years. Originally starting four years ago in npm/npm#8921 with a detailed summary in npm/npm#11632 (comment)

[aeschright]

We use needs-discussion to flag that the team may need to make an internal decision or coordinate with other parts of the organization. In this case, because the change is marked semver-major, the soonest it can be merged will be the npm 7 release in a few months.

[Allactaga]

@aeschright, I am not familiar with the internal processes of the team. Can you please share when the discussion will take place? Will you make sure that this change will go out with npm7 and we don't have to wait for npm8?

[herebebeasties]

@aeschright / @zkat: Why does omitting a log message like this count as public API surface area worthy of a major semver update?

Given that the community clearly would like it fixed (literally hundreds of comments/votes across multiple issues) and that the actual substantial change here is a totally trivial three line patch, that it's so far taken more than four years to look at this given all the activity and comments around it is frankly mind-boggling. It massively puts people off contributing to the project. I certainly wouldn't bother, looking at how all this has been handled. 👎

[jacksonrayhamilton]

@herebebeasties Exactly. You hit the nail on the head. Let NPM burn! 🔥 🔥

@cmedinasoriano, I implore you to close this PR. Let’s let NPM fail. Let’s tell our friends to switch to Yarn because NPM is a poorly-run project.

[jacksonrayhamilton]

NPM can either improve, or die. It may have been a mistake for Node to include this company’s CLI in the Node installation. The company can prove to us whether that’s the case or not. If we will sentiment to change, then a better package manager, or least better stewardship, could be available to us in the future.

[ljharb]

That’s a pretty strong reaction to a PR about a log message.

Speaking as a maintainer myself, the age of an issue does not have any correlation whatsoever to its priority, its risks, or the speed of addressing it.

[jacksonrayhamilton]

I dedicated several hours of my time to learn how the project worked, and in more than one instance provided code and tests, all free of charge. How many people pause their lives to do that?

The first time I did that, they missed my contribution and commented months later that it’d been fixed elsewhere. The second time, I advocated for my change for months, only to see the issue closed by a bot. Scroll through the hundreds of comments and reactions over the past years in relation to this “pitiful, insignificant” log message update to gauge why NPM is truly a poorly-run project.

And at the end of all of it, I get to read snarky comments like yours, implying that I should sit down and shut up. Nope, no more of that.

[ljharb]

I’m not being snarky; but while it’s commendable for you to donate your time and effort, that in no way obligates anyone else to do so, including npm.

[jacksonrayhamilton]

Actually, it does. It’s a rather fundamental concept we humans have of a fair exchange of value.

[ljharb]

No, that concept requires previous agreement. You can’t obligate someone to do work for you just because you decided to do work for them of your own accord, without their cooperation or remuneration or agreement.

What you’re describing is called entitlement, not a fair exchange.

[herebebeasties]

@ljharb

Speaking as a maintainer myself, the age of an issue does not have any correlation whatsoever to its priority, its risks, or the speed of addressing it.

No, quite right. I didn't say it did.
However, I did spell out the low risk of addressing this, the low time impact of reviewing it and the large number of people in the NPM community who are asking for it to be fixed.

When an issue that is literally a trivial three line fix and that has hundreds of people clamouring for you to land the community-provided (!) PR for it, is ignored entirely for four years, and maintainers are spending longer fending off people who are complaining about it rather than just landing the bloody thing, you surely have to concede that you are doing something wrong.

You can trot out the "it's free, you have no right to complain" line if you want to, but you are seriously losing mindshare and goodwill from a community that has already provided a fix for this for you, not once, but about four times over, and just been ignored and ignored for years.

It does not help your cause to then complain at these same people who have provided a fix. It's toxic behaviour and rightly makes them feel pissed.

[herebebeasties]

What you’re describing is called entitlement, not a fair exchange.

Actually, what he is describing is how healthy open source projects work.

I think we would all appreciate it if you could avoid using such personal terminology as "entitlement" (which to me seems totally unwarranted in this case - he provided the patch, which is pretty much the opposite) and concentrated on the actual issue here, which is getting this thing fixed.

In half the time spent antagonising each other on this issue, it could easily have been reviewed and landed.

[ljharb]

@herebebeasties my comment wasn’t directed at you; and the health of an open source project is not generically measured by how fast PRs are merged, nor which are merged. I understand their frustration, but “let npm burn” is not a productive or warranted sentiment to express.

Note; I’m not a maintainer here - there aren’t maintainers “fending off” anyone. I’m just a maintainer of other projects responding to the unjustified vitriol, even if it comes from understandable frustration.

[aeschright]

Unfortunately, since we were let go from npm there's not much I can do about whether this PR gets merged or released. It's very difficult to make progress when there are no resources. I know this has been frustrating for cli users and contributors, but please be aware that the developers who've worked on this project have no control over what the company is doing now.

[jacksonrayhamilton]

I understand their frustration, but “let npm burn” is not a productive or warranted sentiment to express.

What doesn’t kill them can make them stronger. Otherwise, space can be made for a new default package manager for Node, or space can be made for new management for the NPM CLI that ships with Node. As a community we shouldn’t be complacent with the current state of affairs.

I can certainly sympathize with the predicament @aeschright describes. Responsibility travels up to NPM’s management and owners for prioritizing open source work. Are they up to that task? If not, NPM users should take their business elsewhere.

[icavalheiro]

Please merge this T-T
Those fsevents warning have been haunting me for years now, on my windows and linux work machines!

[tomcanham]

Ditto on "please merge" -- I try to get clean builds, and the warning (for fsevents in my case) is annoying.

[emmaffiondavies]

BUMP! This is getting ridiculous, I want my clean build damnit 😢 The best workaround I've found so far is as follows, but it's limited in that it means if you have genuine optional dependencies in your project, then they'll always be ignored (works fine for me as I don't have any):

package.json:

{
"optionalDependencies": {
"fsevents": "*"
}
}

Install with:
npm install --no-optional

[NishealJ]

is this expected to fix npm/npm#18712 ?

[spaceneenja]

It baffles me to think of the literal days which humanity has collectively spent on this issue. Something that seems to be easily fixed with a few lines of code. How many questions, GitHub issues, pull requests, google searches, etc... that this has caused?

NPM is a powerful tool but increasingly it's looking like it's the wrong package manager to be automatically included with Node. There are alternatives which take developer experience more seriously and don't offer up blase responses to concerns provided by the community.

[jacksonrayhamilton]

NPM is a powerful tool but increasingly it's looking like it's the wrong package manager to be automatically included with Node.

Yep. Maybe Node’s maintainers should fork the CLI.

Since people expect an npm program to be installed it might be tricky to replace NPM with Yarn or pnpm; there would have to be a compatibility layer that would turn npm install into a yarn install, convert between lockfile formats, etc.

[ljharb]

A lot of work has been put into npm 7 to resolve the many complex (not trivial) issues with optional deps and logging; just because this PR hasn’t seen movement doesn’t mean the problem is being ignored.

Nothing about FOSS guarantees any PR will be accepted; i think your expectations are set incorrectly.

[darcyclarke]

@cmedinasoriano sorry for the delay here. I'm closing this as we don't print optional dep info/warnings today in v7 & the original issue referenced has also been closed. Appreciate the contribution though.

[markuszeller]

Warnings should be reduced to a minimum and only be given on a non-optional dependency. Seeing always so many warnings attracts unneeded attention.

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.1.2 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.1.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/webpack-dev-server/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/watchpack-chokidar2/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

[karikera]

I don't know why should I be warned even using normal working modules.

[JavierLight]

Does the npm dev team ever heard of the concept "normalization of deviance"?

This should never appear as a warning!!

[Pointotech]

I switched to Yarn on all of my projects because of the ridiculous dysfunction that this thread demonstrates. Haven't seen an fsevents warning since :)

[bibipkins]

its been 2 years since I last visited this thread. still not fixed and I still have to see this garbage in my build logs...

[cmedinasoriano]

The intention of this PR is to continue the discussion on npm/npm#19198
All credits to this fix goes to @jacksonrayhamilton
My only contribution was to apply the same fixes to current npm/cli and opening the discussion again.

This was the PR message for npm/npm#19198 (with corrected issue refs to npm/npm):
Fixesnpm/npm#11632, reducing the log level of nonfatal errors when installing optional dependencies on an unsupported platform (e.g. fsevents on GNU/Linux). Adapts the changes from npm/npm#12841 to the current state of the repo and endeavors to implement the requested changes in this issue comment.

In the last two PRs that attempted to address this, it was suggested a "debug" error level be used, but it does not seem like "debug" exists as an error level in npmlog. "info" seems to have similar intent though, and it does eliminate the message by default:

~/projects/chokidar-test λ cat package.json {
"dependencies": {
"chokidar": "^1.7.0"
}
}
~/projects/chokidar-test λ npm i
npm WARN chokidar-test No description
npm WARN chokidar-test No repository field.
npm WARN chokidar-test No license field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.1.3 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
added 116 packages in 4.831s
~/projects/chokidar-test λ ../npm/bin/npm-cli.js i
npm WARN chokidar-test No description
npm WARN chokidar-test No repository field.
npm WARN chokidar-test No license field.
added 116 packages in 4.122s

[13rac1]

@zkat I suggest not labeling this needs-discussion. This issue has already been bikeshed for years. Originally starting four years ago in npm/npm#8921 with a detailed summary in npm/npm#11632 (comment)

[aeschright]

We use needs-discussion to flag that the team may need to make an internal decision or coordinate with other parts of the organization. In this case, because the change is marked semver-major, the soonest it can be merged will be the npm 7 release in a few months.

[Allactaga]

@aeschright, I am not familiar with the internal processes of the team. Can you please share when the discussion will take place? Will you make sure that this change will go out with npm7 and we don't have to wait for npm8?

[herebebeasties]

@aeschright / @zkat: Why does omitting a log message like this count as public API surface area worthy of a major semver update?

Given that the community clearly would like it fixed (literally hundreds of comments/votes across multiple issues) and that the actual substantial change here is a totally trivial three line patch, that it's so far taken more than four years to look at this given all the activity and comments around it is frankly mind-boggling. It massively puts people off contributing to the project. I certainly wouldn't bother, looking at how all this has been handled. 👎

[jacksonrayhamilton]

@herebebeasties Exactly. You hit the nail on the head. Let NPM burn! 🔥 🔥

@cmedinasoriano, I implore you to close this PR. Let’s let NPM fail. Let’s tell our friends to switch to Yarn because NPM is a poorly-run project.

[jacksonrayhamilton]

NPM can either improve, or die. It may have been a mistake for Node to include this company’s CLI in the Node installation. The company can prove to us whether that’s the case or not. If we will sentiment to change, then a better package manager, or least better stewardship, could be available to us in the future.

[ljharb]

That’s a pretty strong reaction to a PR about a log message.

Speaking as a maintainer myself, the age of an issue does not have any correlation whatsoever to its priority, its risks, or the speed of addressing it.

[jacksonrayhamilton]

I dedicated several hours of my time to learn how the project worked, and in more than one instance provided code and tests, all free of charge. How many people pause their lives to do that?

The first time I did that, they missed my contribution and commented months later that it’d been fixed elsewhere. The second time, I advocated for my change for months, only to see the issue closed by a bot. Scroll through the hundreds of comments and reactions over the past years in relation to this “pitiful, insignificant” log message update to gauge why NPM is truly a poorly-run project.

And at the end of all of it, I get to read snarky comments like yours, implying that I should sit down and shut up. Nope, no more of that.

[ljharb]

I’m not being snarky; but while it’s commendable for you to donate your time and effort, that in no way obligates anyone else to do so, including npm.

[jacksonrayhamilton]

Actually, it does. It’s a rather fundamental concept we humans have of a fair exchange of value.

[ljharb]

No, that concept requires previous agreement. You can’t obligate someone to do work for you just because you decided to do work for them of your own accord, without their cooperation or remuneration or agreement.

What you’re describing is called entitlement, not a fair exchange.

[herebebeasties]

@ljharb

Speaking as a maintainer myself, the age of an issue does not have any correlation whatsoever to its priority, its risks, or the speed of addressing it.

No, quite right. I didn't say it did.
However, I did spell out the low risk of addressing this, the low time impact of reviewing it and the large number of people in the NPM community who are asking for it to be fixed.

When an issue that is literally a trivial three line fix and that has hundreds of people clamouring for you to land the community-provided (!) PR for it, is ignored entirely for four years, and maintainers are spending longer fending off people who are complaining about it rather than just landing the bloody thing, you surely have to concede that you are doing something wrong.

You can trot out the "it's free, you have no right to complain" line if you want to, but you are seriously losing mindshare and goodwill from a community that has already provided a fix for this for you, not once, but about four times over, and just been ignored and ignored for years.

It does not help your cause to then complain at these same people who have provided a fix. It's toxic behaviour and rightly makes them feel pissed.

[herebebeasties]

What you’re describing is called entitlement, not a fair exchange.

Actually, what he is describing is how healthy open source projects work.

I think we would all appreciate it if you could avoid using such personal terminology as "entitlement" (which to me seems totally unwarranted in this case - he provided the patch, which is pretty much the opposite) and concentrated on the actual issue here, which is getting this thing fixed.

In half the time spent antagonising each other on this issue, it could easily have been reviewed and landed.

[ljharb]

@herebebeasties my comment wasn’t directed at you; and the health of an open source project is not generically measured by how fast PRs are merged, nor which are merged. I understand their frustration, but “let npm burn” is not a productive or warranted sentiment to express.

Note; I’m not a maintainer here - there aren’t maintainers “fending off” anyone. I’m just a maintainer of other projects responding to the unjustified vitriol, even if it comes from understandable frustration.

[aeschright]

Unfortunately, since we were let go from npm there's not much I can do about whether this PR gets merged or released. It's very difficult to make progress when there are no resources. I know this has been frustrating for cli users and contributors, but please be aware that the developers who've worked on this project have no control over what the company is doing now.

[jacksonrayhamilton]

I understand their frustration, but “let npm burn” is not a productive or warranted sentiment to express.

What doesn’t kill them can make them stronger. Otherwise, space can be made for a new default package manager for Node, or space can be made for new management for the NPM CLI that ships with Node. As a community we shouldn’t be complacent with the current state of affairs.

I can certainly sympathize with the predicament @aeschright describes. Responsibility travels up to NPM’s management and owners for prioritizing open source work. Are they up to that task? If not, NPM users should take their business elsewhere.

[icavalheiro]

Please merge this T-T
Those fsevents warning have been haunting me for years now, on my windows and linux work machines!

[tomcanham]

Ditto on "please merge" -- I try to get clean builds, and the warning (for fsevents in my case) is annoying.

[emmaffiondavies]

BUMP! This is getting ridiculous, I want my clean build damnit 😢 The best workaround I've found so far is as follows, but it's limited in that it means if you have genuine optional dependencies in your project, then they'll always be ignored (works fine for me as I don't have any):

package.json:

{
"optionalDependencies": {
"fsevents": "*"
}
}

Install with:
npm install --no-optional

[NishealJ]

is this expected to fix npm/npm#18712 ?

[spaceneenja]

It baffles me to think of the literal days which humanity has collectively spent on this issue. Something that seems to be easily fixed with a few lines of code. How many questions, GitHub issues, pull requests, google searches, etc... that this has caused?

NPM is a powerful tool but increasingly it's looking like it's the wrong package manager to be automatically included with Node. There are alternatives which take developer experience more seriously and don't offer up blase responses to concerns provided by the community.

[jacksonrayhamilton]

NPM is a powerful tool but increasingly it's looking like it's the wrong package manager to be automatically included with Node.

Yep. Maybe Node’s maintainers should fork the CLI.

Since people expect an npm program to be installed it might be tricky to replace NPM with Yarn or pnpm; there would have to be a compatibility layer that would turn npm install into a yarn install, convert between lockfile formats, etc.

[ljharb]

A lot of work has been put into npm 7 to resolve the many complex (not trivial) issues with optional deps and logging; just because this PR hasn’t seen movement doesn’t mean the problem is being ignored.

Nothing about FOSS guarantees any PR will be accepted; i think your expectations are set incorrectly.

[darcyclarke]

@cmedinasoriano sorry for the delay here. I'm closing this as we don't print optional dep info/warnings today in v7 & the original issue referenced has also been closed. Appreciate the contribution though.

[markuszeller]

Warnings should be reduced to a minimum and only be given on a non-optional dependency. Seeing always so many warnings attracts unneeded attention.

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.1.2 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.1.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/webpack-dev-server/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/watchpack-chokidar2/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

[karikera]

I don't know why should I be warned even using normal working modules.

[JavierLight]

Does the npm dev team ever heard of the concept "normalization of deviance"?

This should never appear as a warning!!

[Pointotech]

I switched to Yarn on all of my projects because of the ridiculous dysfunction that this thread demonstrates. Haven't seen an fsevents warning since :)

[bibipkins]

its been 2 years since I last visited this thread. still not fixed and I still have to see this garbage in my build logs...

[cmedinasoriano]

The intention of this PR is to continue the discussion on npm/npm#19198
All credits to this fix goes to @jacksonrayhamilton
My only contribution was to apply the same fixes to current npm/cli and opening the discussion again.

This was the PR message for npm/npm#19198 (with corrected issue refs to npm/npm):
Fixesnpm/npm#11632, reducing the log level of nonfatal errors when installing optional dependencies on an unsupported platform (e.g. fsevents on GNU/Linux). Adapts the changes from npm/npm#12841 to the current state of the repo and endeavors to implement the requested changes in this issue comment.

In the last two PRs that attempted to address this, it was suggested a "debug" error level be used, but it does not seem like "debug" exists as an error level in npmlog. "info" seems to have similar intent though, and it does eliminate the message by default:

~/projects/chokidar-test λ cat package.json {
"dependencies": {
"chokidar": "^1.7.0"
}
}
~/projects/chokidar-test λ npm i
npm WARN chokidar-test No description
npm WARN chokidar-test No repository field.
npm WARN chokidar-test No license field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.1.3 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
added 116 packages in 4.831s
~/projects/chokidar-test λ ../npm/bin/npm-cli.js i
npm WARN chokidar-test No description
npm WARN chokidar-test No repository field.
npm WARN chokidar-test No license field.
added 116 packages in 4.122s

[13rac1]

@zkat I suggest not labeling this needs-discussion. This issue has already been bikeshed for years. Originally starting four years ago in npm/npm#8921 with a detailed summary in npm/npm#11632 (comment)

[aeschright]

We use needs-discussion to flag that the team may need to make an internal decision or coordinate with other parts of the organization. In this case, because the change is marked semver-major, the soonest it can be merged will be the npm 7 release in a few months.

[Allactaga]

@aeschright, I am not familiar with the internal processes of the team. Can you please share when the discussion will take place? Will you make sure that this change will go out with npm7 and we don't have to wait for npm8?

[herebebeasties]

@aeschright / @zkat: Why does omitting a log message like this count as public API surface area worthy of a major semver update?

Given that the community clearly would like it fixed (literally hundreds of comments/votes across multiple issues) and that the actual substantial change here is a totally trivial three line patch, that it's so far taken more than four years to look at this given all the activity and comments around it is frankly mind-boggling. It massively puts people off contributing to the project. I certainly wouldn't bother, looking at how all this has been handled. 👎

[jacksonrayhamilton]

@herebebeasties Exactly. You hit the nail on the head. Let NPM burn! 🔥 🔥

@cmedinasoriano, I implore you to close this PR. Let’s let NPM fail. Let’s tell our friends to switch to Yarn because NPM is a poorly-run project.

[jacksonrayhamilton]

NPM can either improve, or die. It may have been a mistake for Node to include this company’s CLI in the Node installation. The company can prove to us whether that’s the case or not. If we will sentiment to change, then a better package manager, or least better stewardship, could be available to us in the future.

[ljharb]

That’s a pretty strong reaction to a PR about a log message.

Speaking as a maintainer myself, the age of an issue does not have any correlation whatsoever to its priority, its risks, or the speed of addressing it.

[jacksonrayhamilton]

I dedicated several hours of my time to learn how the project worked, and in more than one instance provided code and tests, all free of charge. How many people pause their lives to do that?

The first time I did that, they missed my contribution and commented months later that it’d been fixed elsewhere. The second time, I advocated for my change for months, only to see the issue closed by a bot. Scroll through the hundreds of comments and reactions over the past years in relation to this “pitiful, insignificant” log message update to gauge why NPM is truly a poorly-run project.

And at the end of all of it, I get to read snarky comments like yours, implying that I should sit down and shut up. Nope, no more of that.

[ljharb]

I’m not being snarky; but while it’s commendable for you to donate your time and effort, that in no way obligates anyone else to do so, including npm.

[jacksonrayhamilton]

Actually, it does. It’s a rather fundamental concept we humans have of a fair exchange of value.

[ljharb]

No, that concept requires previous agreement. You can’t obligate someone to do work for you just because you decided to do work for them of your own accord, without their cooperation or remuneration or agreement.

What you’re describing is called entitlement, not a fair exchange.

[herebebeasties]

@ljharb

Speaking as a maintainer myself, the age of an issue does not have any correlation whatsoever to its priority, its risks, or the speed of addressing it.

No, quite right. I didn't say it did.
However, I did spell out the low risk of addressing this, the low time impact of reviewing it and the large number of people in the NPM community who are asking for it to be fixed.

When an issue that is literally a trivial three line fix and that has hundreds of people clamouring for you to land the community-provided (!) PR for it, is ignored entirely for four years, and maintainers are spending longer fending off people who are complaining about it rather than just landing the bloody thing, you surely have to concede that you are doing something wrong.

You can trot out the "it's free, you have no right to complain" line if you want to, but you are seriously losing mindshare and goodwill from a community that has already provided a fix for this for you, not once, but about four times over, and just been ignored and ignored for years.

It does not help your cause to then complain at these same people who have provided a fix. It's toxic behaviour and rightly makes them feel pissed.

[herebebeasties]

What you’re describing is called entitlement, not a fair exchange.

Actually, what he is describing is how healthy open source projects work.

I think we would all appreciate it if you could avoid using such personal terminology as "entitlement" (which to me seems totally unwarranted in this case - he provided the patch, which is pretty much the opposite) and concentrated on the actual issue here, which is getting this thing fixed.

In half the time spent antagonising each other on this issue, it could easily have been reviewed and landed.

[ljharb]

@herebebeasties my comment wasn’t directed at you; and the health of an open source project is not generically measured by how fast PRs are merged, nor which are merged. I understand their frustration, but “let npm burn” is not a productive or warranted sentiment to express.

Note; I’m not a maintainer here - there aren’t maintainers “fending off” anyone. I’m just a maintainer of other projects responding to the unjustified vitriol, even if it comes from understandable frustration.

[aeschright]

Unfortunately, since we were let go from npm there's not much I can do about whether this PR gets merged or released. It's very difficult to make progress when there are no resources. I know this has been frustrating for cli users and contributors, but please be aware that the developers who've worked on this project have no control over what the company is doing now.

[jacksonrayhamilton]

I understand their frustration, but “let npm burn” is not a productive or warranted sentiment to express.

What doesn’t kill them can make them stronger. Otherwise, space can be made for a new default package manager for Node, or space can be made for new management for the NPM CLI that ships with Node. As a community we shouldn’t be complacent with the current state of affairs.

I can certainly sympathize with the predicament @aeschright describes. Responsibility travels up to NPM’s management and owners for prioritizing open source work. Are they up to that task? If not, NPM users should take their business elsewhere.

[icavalheiro]

Please merge this T-T
Those fsevents warning have been haunting me for years now, on my windows and linux work machines!

[tomcanham]

Ditto on "please merge" -- I try to get clean builds, and the warning (for fsevents in my case) is annoying.

[emmaffiondavies]

BUMP! This is getting ridiculous, I want my clean build damnit 😢 The best workaround I've found so far is as follows, but it's limited in that it means if you have genuine optional dependencies in your project, then they'll always be ignored (works fine for me as I don't have any):

package.json:

{
"optionalDependencies": {
"fsevents": "*"
}
}

Install with:
npm install --no-optional

[NishealJ]

is this expected to fix npm/npm#18712 ?

[spaceneenja]

It baffles me to think of the literal days which humanity has collectively spent on this issue. Something that seems to be easily fixed with a few lines of code. How many questions, GitHub issues, pull requests, google searches, etc... that this has caused?

NPM is a powerful tool but increasingly it's looking like it's the wrong package manager to be automatically included with Node. There are alternatives which take developer experience more seriously and don't offer up blase responses to concerns provided by the community.

[jacksonrayhamilton]

NPM is a powerful tool but increasingly it's looking like it's the wrong package manager to be automatically included with Node.

Yep. Maybe Node’s maintainers should fork the CLI.

Since people expect an npm program to be installed it might be tricky to replace NPM with Yarn or pnpm; there would have to be a compatibility layer that would turn npm install into a yarn install, convert between lockfile formats, etc.

[ljharb]

A lot of work has been put into npm 7 to resolve the many complex (not trivial) issues with optional deps and logging; just because this PR hasn’t seen movement doesn’t mean the problem is being ignored.

Nothing about FOSS guarantees any PR will be accepted; i think your expectations are set incorrectly.

[darcyclarke]

@cmedinasoriano sorry for the delay here. I'm closing this as we don't print optional dep info/warnings today in v7 & the original issue referenced has also been closed. Appreciate the contribution though.

[markuszeller]

Warnings should be reduced to a minimum and only be given on a non-optional dependency. Seeing always so many warnings attracts unneeded attention.

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.1.2 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.1.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/webpack-dev-server/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/watchpack-chokidar2/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

[karikera]

I don't know why should I be warned even using normal working modules.

[JavierLight]

Does the npm dev team ever heard of the concept "normalization of deviance"?

This should never appear as a warning!!

[Pointotech]

I switched to Yarn on all of my projects because of the ridiculous dysfunction that this thread demonstrates. Haven't seen an fsevents warning since :)

[bibipkins]

its been 2 years since I last visited this thread. still not fixed and I still have to see this garbage in my build logs...

[cmedinasoriano]

The intention of this PR is to continue the discussion on npm/npm#19198
All credits to this fix goes to @jacksonrayhamilton
My only contribution was to apply the same fixes to current npm/cli and opening the discussion again.

This was the PR message for npm/npm#19198 (with corrected issue refs to npm/npm):
Fixesnpm/npm#11632, reducing the log level of nonfatal errors when installing optional dependencies on an unsupported platform (e.g. fsevents on GNU/Linux). Adapts the changes from npm/npm#12841 to the current state of the repo and endeavors to implement the requested changes in this issue comment.

In the last two PRs that attempted to address this, it was suggested a "debug" error level be used, but it does not seem like "debug" exists as an error level in npmlog. "info" seems to have similar intent though, and it does eliminate the message by default:

~/projects/chokidar-test λ cat package.json {
"dependencies": {
"chokidar": "^1.7.0"
}
}
~/projects/chokidar-test λ npm i
npm WARN chokidar-test No description
npm WARN chokidar-test No repository field.
npm WARN chokidar-test No license field.
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.1.3 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.1.3: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
added 116 packages in 4.831s
~/projects/chokidar-test λ ../npm/bin/npm-cli.js i
npm WARN chokidar-test No description
npm WARN chokidar-test No repository field.
npm WARN chokidar-test No license field.
added 116 packages in 4.122s

[13rac1]

@zkat I suggest not labeling this needs-discussion. This issue has already been bikeshed for years. Originally starting four years ago in npm/npm#8921 with a detailed summary in npm/npm#11632 (comment)

[aeschright]

We use needs-discussion to flag that the team may need to make an internal decision or coordinate with other parts of the organization. In this case, because the change is marked semver-major, the soonest it can be merged will be the npm 7 release in a few months.

[Allactaga]

@aeschright, I am not familiar with the internal processes of the team. Can you please share when the discussion will take place? Will you make sure that this change will go out with npm7 and we don't have to wait for npm8?

[herebebeasties]

@aeschright / @zkat: Why does omitting a log message like this count as public API surface area worthy of a major semver update?

Given that the community clearly would like it fixed (literally hundreds of comments/votes across multiple issues) and that the actual substantial change here is a totally trivial three line patch, that it's so far taken more than four years to look at this given all the activity and comments around it is frankly mind-boggling. It massively puts people off contributing to the project. I certainly wouldn't bother, looking at how all this has been handled. 👎

[jacksonrayhamilton]

@herebebeasties Exactly. You hit the nail on the head. Let NPM burn! 🔥 🔥

@cmedinasoriano, I implore you to close this PR. Let’s let NPM fail. Let’s tell our friends to switch to Yarn because NPM is a poorly-run project.

[jacksonrayhamilton]

NPM can either improve, or die. It may have been a mistake for Node to include this company’s CLI in the Node installation. The company can prove to us whether that’s the case or not. If we will sentiment to change, then a better package manager, or least better stewardship, could be available to us in the future.

[ljharb]

That’s a pretty strong reaction to a PR about a log message.

Speaking as a maintainer myself, the age of an issue does not have any correlation whatsoever to its priority, its risks, or the speed of addressing it.

[jacksonrayhamilton]

I dedicated several hours of my time to learn how the project worked, and in more than one instance provided code and tests, all free of charge. How many people pause their lives to do that?

The first time I did that, they missed my contribution and commented months later that it’d been fixed elsewhere. The second time, I advocated for my change for months, only to see the issue closed by a bot. Scroll through the hundreds of comments and reactions over the past years in relation to this “pitiful, insignificant” log message update to gauge why NPM is truly a poorly-run project.

And at the end of all of it, I get to read snarky comments like yours, implying that I should sit down and shut up. Nope, no more of that.

[ljharb]

I’m not being snarky; but while it’s commendable for you to donate your time and effort, that in no way obligates anyone else to do so, including npm.

[jacksonrayhamilton]

Actually, it does. It’s a rather fundamental concept we humans have of a fair exchange of value.

[ljharb]

No, that concept requires previous agreement. You can’t obligate someone to do work for you just because you decided to do work for them of your own accord, without their cooperation or remuneration or agreement.

What you’re describing is called entitlement, not a fair exchange.

[herebebeasties]

@ljharb

Speaking as a maintainer myself, the age of an issue does not have any correlation whatsoever to its priority, its risks, or the speed of addressing it.

No, quite right. I didn't say it did.
However, I did spell out the low risk of addressing this, the low time impact of reviewing it and the large number of people in the NPM community who are asking for it to be fixed.

When an issue that is literally a trivial three line fix and that has hundreds of people clamouring for you to land the community-provided (!) PR for it, is ignored entirely for four years, and maintainers are spending longer fending off people who are complaining about it rather than just landing the bloody thing, you surely have to concede that you are doing something wrong.

You can trot out the "it's free, you have no right to complain" line if you want to, but you are seriously losing mindshare and goodwill from a community that has already provided a fix for this for you, not once, but about four times over, and just been ignored and ignored for years.

It does not help your cause to then complain at these same people who have provided a fix. It's toxic behaviour and rightly makes them feel pissed.

[herebebeasties]

What you’re describing is called entitlement, not a fair exchange.

Actually, what he is describing is how healthy open source projects work.

I think we would all appreciate it if you could avoid using such personal terminology as "entitlement" (which to me seems totally unwarranted in this case - he provided the patch, which is pretty much the opposite) and concentrated on the actual issue here, which is getting this thing fixed.

In half the time spent antagonising each other on this issue, it could easily have been reviewed and landed.

[ljharb]

@herebebeasties my comment wasn’t directed at you; and the health of an open source project is not generically measured by how fast PRs are merged, nor which are merged. I understand their frustration, but “let npm burn” is not a productive or warranted sentiment to express.

Note; I’m not a maintainer here - there aren’t maintainers “fending off” anyone. I’m just a maintainer of other projects responding to the unjustified vitriol, even if it comes from understandable frustration.

[aeschright]

Unfortunately, since we were let go from npm there's not much I can do about whether this PR gets merged or released. It's very difficult to make progress when there are no resources. I know this has been frustrating for cli users and contributors, but please be aware that the developers who've worked on this project have no control over what the company is doing now.

[jacksonrayhamilton]

I understand their frustration, but “let npm burn” is not a productive or warranted sentiment to express.

What doesn’t kill them can make them stronger. Otherwise, space can be made for a new default package manager for Node, or space can be made for new management for the NPM CLI that ships with Node. As a community we shouldn’t be complacent with the current state of affairs.

I can certainly sympathize with the predicament @aeschright describes. Responsibility travels up to NPM’s management and owners for prioritizing open source work. Are they up to that task? If not, NPM users should take their business elsewhere.

[icavalheiro]

Please merge this T-T
Those fsevents warning have been haunting me for years now, on my windows and linux work machines!

[tomcanham]

Ditto on "please merge" -- I try to get clean builds, and the warning (for fsevents in my case) is annoying.

[emmaffiondavies]

BUMP! This is getting ridiculous, I want my clean build damnit 😢 The best workaround I've found so far is as follows, but it's limited in that it means if you have genuine optional dependencies in your project, then they'll always be ignored (works fine for me as I don't have any):

package.json:

{
"optionalDependencies": {
"fsevents": "*"
}
}

Install with:
npm install --no-optional

[NishealJ]

is this expected to fix npm/npm#18712 ?

[spaceneenja]

It baffles me to think of the literal days which humanity has collectively spent on this issue. Something that seems to be easily fixed with a few lines of code. How many questions, GitHub issues, pull requests, google searches, etc... that this has caused?

NPM is a powerful tool but increasingly it's looking like it's the wrong package manager to be automatically included with Node. There are alternatives which take developer experience more seriously and don't offer up blase responses to concerns provided by the community.

[jacksonrayhamilton]

NPM is a powerful tool but increasingly it's looking like it's the wrong package manager to be automatically included with Node.

Yep. Maybe Node’s maintainers should fork the CLI.

Since people expect an npm program to be installed it might be tricky to replace NPM with Yarn or pnpm; there would have to be a compatibility layer that would turn npm install into a yarn install, convert between lockfile formats, etc.

[ljharb]

A lot of work has been put into npm 7 to resolve the many complex (not trivial) issues with optional deps and logging; just because this PR hasn’t seen movement doesn’t mean the problem is being ignored.

Nothing about FOSS guarantees any PR will be accepted; i think your expectations are set incorrectly.

[darcyclarke]

@cmedinasoriano sorry for the delay here. I'm closing this as we don't print optional dep info/warnings today in v7 & the original issue referenced has also been closed. Appreciate the contribution though.

[markuszeller]

Warnings should be reduced to a minimum and only be given on a non-optional dependency. Seeing always so many warnings attracts unneeded attention.

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@2.1.2 (node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@2.1.2: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/webpack-dev-server/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})
npm WARN optional SKIPPING OPTIONAL DEPENDENCY: fsevents@1.2.13 (node_modules/watchpack-chokidar2/node_modules/fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for fsevents@1.2.13: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"})

[karikera]

I don't know why should I be warned even using normal working modules.

[JavierLight]

Does the npm dev team ever heard of the concept "normalization of deviance"?

This should never appear as a warning!!

[Pointotech]

I switched to Yarn on all of my projects because of the ridiculous dysfunction that this thread demonstrates. Haven't seen an fsevents warning since :)

[bibipkins]

its been 2 years since I last visited this thread. still not fixed and I still have to see this garbage in my build logs...