windows: fsevents v1 is getting built #301

aljopro · 2019-12-20T16:36:53Z

When doing an install of dependecies on my windows based system, fsevents 1.2.11 attempts to run node-gyp, asking for Python. When Python is not found node-gyp sets the exitcode to npm as non-zero. This causes our CI to fail the build.

It seems that fsevents could do a check ahead of time for a darwin based system before calling node-gyp since fsevents is strictly for darwin systems.

Below is the captured output:

> fsevents@1.2.11 install C:\Users\jchappell\Projects\wida\alkami.client.widget.myaccountsv3\node_modules\fsevents
> node-gyp rebuild


C:\Users\jchappell\Projects\wida\alkami.client.widget.myaccountsv3\node_modules\fsevents>if not defined npm_config_node_gyp (node "C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js" rebuild )
gyp info it worked if it ends with ok
gyp info using node-gyp@3.8.0
gyp info using node@10.16.3 | win32 | x64
gyp ERR! configure error
gyp ERR! stack Error: Can't find Python executable "python", you can set the PYTHON env variable.
gyp ERR! stack     at PythonFinder.failNoPython (C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\lib\configure.js:484:19)
gyp ERR! stack     at PythonFinder.<anonymous> (C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\lib\configure.js:509:16)
gyp ERR! stack     at C:\Program Files\nodejs\node_modules\npm\node_modules\graceful-fs\polyfills.js:282:31
gyp ERR! stack     at FSReqWrap.oncomplete (fs.js:153:21)
gyp ERR! System Windows_NT 10.0.18362
gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd C:\Users\jchappell\Projects\wida\alkami.client.widget.myaccountsv3\node_modules\fsevents
gyp ERR! node -v v10.16.3
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok

The text was updated successfully, but these errors were encountered:

paulmillr · 2019-12-20T20:31:09Z

You should update to chokidar 3 / fsevents 2. fsevents 1 is unsupported.

This happens because of NPM bug. See the comment below from @guidobouman:

If you really need npm ci to work on windows environments, you can (temporarily) lock the version in your own dependencies list:

{
  ...
  "optionalDependencies": {
    "fsevents": "1.2.9"
  },
  "_comment": "fsevent@1.2.9 is locked in to prevent broken builds on windows for v1.2.11"
}

This works until the issue is resolved in a more sustainable manner at npm or fsevents.

Do note: This breaks when you run Node v13, as the binaries are not available for that version.

pelepelin · 2019-12-25T16:06:56Z

If it's unsupported, why 1.2.11 was released 12 days ago breaking existing projects where 1.2.9 did not?
Please, fix.

paulmillr · 2019-12-25T16:58:48Z

1.2.9 was downloading binaries from AWS to which we no longer have access to. There were no binaries for node 13 which made 1.2.9 unusable for people on node 13. Which is why we released 1.2.11, so that people are able to build it now. If the software doesn’t build on your system, it’s system’s problem. You need python now etc.

paulmillr · 2019-12-25T16:59:09Z

2.x doesn’t require any of those, which is why we recommend it.

pelepelin · 2019-12-25T17:35:02Z

yep, sorry, I did not look into original report, which relates to missing build dependencies.

However, my Windows system has the build dependencies installed, it reports a different error, which actually does not fail the install.

> fsevents@1.2.11 install [...]\node_modules\@babel\cli\node_modules\fsevents
> node-gyp rebuild


[...]\node_modules\@babel\cli\node_modules\fsevents>if not defined npm_config_node_gyp (node "C:\ProgramData\nvm\v12.13.1\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "C:\ProgramData\nvm\v12.13.1\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js" rebuild )
Traceback (most recent call last):
  File "C:\ProgramData\nvm\v12.13.1\node_modules\npm\node_modules\node-gyp\gyp\gyp_main.py", line 50, in <module>
    sys.exit(gyp.script_main())
  File "C:\ProgramData\nvm\v12.13.1\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 554, in script_main
    return main(sys.argv[1:])
  File "C:\ProgramData\nvm\v12.13.1\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 547, in main
    return gyp_main(args)
  File "C:\ProgramData\nvm\v12.13.1\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 532, in gyp_main
    generator.GenerateOutput(flat_list, targets, data, params)
  File "C:\ProgramData\nvm\v12.13.1\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\generator\msvs.py", line 2034, in GenerateOutput
    sln_projects, project_objects, flat=msvs_version.FlatSolution())
  File "C:\ProgramData\nvm\v12.13.1\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\generator\msvs.py", line 1791, in _GatherSolutionFolders
    return _DictsToFolders('', root, flat)
  File "C:\ProgramData\nvm\v12.13.1\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\generator\msvs.py", line 1744, in _DictsToFolders
    for folder, contents in bucket.items():
AttributeError: 'MSVSProject' object has no attribute 'items'
gyp ERR! configure error
gyp ERR! stack Error: `gyp` failed with exit code: 1

paulmillr · 2019-12-25T18:45:23Z

Interesting. fsevents should not build at windows at all. Not sure why this happens -- package.json field "os" should block the compilation. cc @pipobscure

aljopro · 2019-12-25T19:45:48Z

Interesting. fsevents should not build at windows at all. Not sure why this happens -- package.json field "os" should block the compilation. cc @pipobscure

I guess this was my point. If windows had python or not, the package shouldn’t even be trying to compile on Windows because it’s not needed.

My fault for not explicitly saying I was on a Windows machine in the description.

aljopro · 2019-12-25T20:00:57Z

yep, sorry, I did not look into original report, which relates to missing build dependencies.

However, my Windows system has the build dependencies installed, it reports a different error, which actually does not fail the install.

> fsevents@1.2.11 install [...]\node_modules\@babel\cli\node_modules\fsevents
> node-gyp rebuild


[...]\node_modules\@babel\cli\node_modules\fsevents>if not defined npm_config_node_gyp (node "C:\ProgramData\nvm\v12.13.1\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "C:\ProgramData\nvm\v12.13.1\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js" rebuild )
Traceback (most recent call last):
  File "C:\ProgramData\nvm\v12.13.1\node_modules\npm\node_modules\node-gyp\gyp\gyp_main.py", line 50, in <module>
    sys.exit(gyp.script_main())
  File "C:\ProgramData\nvm\v12.13.1\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 554, in script_main
    return main(sys.argv[1:])
  File "C:\ProgramData\nvm\v12.13.1\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 547, in main
    return gyp_main(args)
  File "C:\ProgramData\nvm\v12.13.1\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 532, in gyp_main
    generator.GenerateOutput(flat_list, targets, data, params)
  File "C:\ProgramData\nvm\v12.13.1\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\generator\msvs.py", line 2034, in GenerateOutput
    sln_projects, project_objects, flat=msvs_version.FlatSolution())
  File "C:\ProgramData\nvm\v12.13.1\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\generator\msvs.py", line 1791, in _GatherSolutionFolders
    return _DictsToFolders('', root, flat)
  File "C:\ProgramData\nvm\v12.13.1\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\generator\msvs.py", line 1744, in _DictsToFolders
    for folder, contents in bucket.items():
AttributeError: 'MSVSProject' object has no attribute 'items'
gyp ERR! configure error
gyp ERR! stack Error: `gyp` failed with exit code: 1

Yeah it’s interesting, I would get a successful install but the exit code returned from npm was 1. This set the lastexitcode environment variable to be set. This caused my automated CI build to fail.

ekravtsova · 2019-12-26T09:29:43Z

We have the same issue.

seangwright · 2019-12-27T18:32:03Z

Running npm ci is causing this node-gyp build in our application which fails in our build environment and locally.

We are using Windows 10 x64.

Here is our dependency tree

$ npm ls fsevents
...
`-- sass@1.24.0
  `-- chokidar@2.1.8
    `-- UNMET OPTIONAL DEPENDENCY fsevents@1.2.11

Here is the log of the fsevents build attempt

> fsevents@1.2.11 install C:\dev\projects\our_project\node_modules\fsevents
> node-gyp rebuild

Updating to the latest chokidar@3.3.1 doesn't help because other packages depend on the ^2.0.0 range of chokidar

$ npm ls fsevents
...
+-- @vue/cli-service@4.1.1
| `-- webpack-dev-server@3.10.1
|   `-- chokidar@2.1.8
|     `-- UNMET OPTIONAL DEPENDENCY fsevents@1.2.11
+-- sass@1.24.0
| `-- chokidar@3.3.1
|   `-- fsevents@2.1.2
`-- webpack@4.41.5
  `-- watchpack@1.6.0
    `-- chokidar@2.1.8
      `-- UNMET OPTIONAL DEPENDENCY fsevents@1.2.11

Node / npm version:

$ node -v
v12.13.1

$ npm -v
6.12.1

For now I'm going to switch our CI/CD process to use npm i instead of npm ci, since npm i works fine.

paulmillr · 2019-12-28T01:54:35Z

So this is what I have been talking about @pipobscure

webpack/webpack-dev-server#2351

Webpack, and tons of other dependencies cannot just bump fsevents to v2, because they still support node v6 etc. We should not just "ditch" fsevents v1 for at least 3-6 months YET.

Can we get new AWS binaries? Or can you describe what do I need to do to set up an AWS account with the binaries? I understand how to host files, but I don't know which exactly files should lie there.

guidobouman · 2020-01-06T17:39:55Z

npm ci ignores the os field in package.json. I've raised a bug in the npm repo. fsevents@1.2.9 still works, because it downloads the executables. Where 1.2.11 does not, because it tries to compile them. When npm ci is run, the package is installed regardless of the os field, and node-gyp is always executed. This causes very old (npm@3) errors to reappear on Windows CI environments.

guidobouman · 2020-01-07T09:30:47Z

Bonus: Because 1.2.11 was released as a patch version, I now have to manually rollback each package-lock.json that updates a dependency that has fsevent 1.x as a deep dependency, even if the package that leans on fsevents has not changed (webpack in my case).

This gets really annoying really quickly. Especially when you have a set of shared packages that you actively develop on and update multiple times a day throughout multiple different projects. I think you can imagine this matrix of changes where I constantly have to rollback a package.json.

paulmillr · 2020-01-07T09:46:05Z

I know this is annoying, but GYP is a ticking time bomb. All the dependencies really need to upgrade to fsevents v2.

guidobouman · 2020-01-07T14:47:39Z

I get that. To help I've also raised an issue with watchpack. But creating a patch release that breaks other environments will give you even more Github issues. On top of that it goes directly against semver. I don't think that is a great idea for the 1.x branch.

paulmillr · 2020-01-08T07:42:15Z

I talked with @pipobscure. Initially i've thought he has added binary hosting on AWS. Apparently, the S3 storage was added in 96e1ace via PR #59.

We (maintainers of fsevents) don't have access to the S3 storage. Which makes it unsafe to use. Adversaries could've replaced binaries with rogue software that steals credentials.

This could be fixed by someone diving into .travis.yml for fsevents v1.2 and deciphering the way fsevents binaries are published. As soon as we understand how they're built, we can set up a new S3 account, and publish binaries for v1.2.11.

guidobouman · 2020-01-08T11:28:27Z

In 1.2.10 binaries were still being published to:
https://fsevents-binaries.s3-us-west-2.amazonaws.com

See 909af26#diff-b9cfc7f2cdf78a7f4b91a753d10865a2L27 for more info.

This URL can be changed to a new S3 bucket. Combined with a new environment var in Travis, node-pre-gyp can push to that to the new bucket.

paulmillr · 2020-01-08T11:50:09Z

I don't understand. If i'm publishing the binary from macos with node v12, how will a node v13 binary appear?

pipobscure · 2020-01-08T12:00:28Z

The old travis.yml ran with all versions of node each then pushing the compile result to S3 somehow.

guidobouman · 2020-01-08T12:25:45Z

Travis is configured with a matrix:

fsevents/.travis.yml

Lines 7 to 14 in 909af26

    
           matrix: 
        
             - NODE_VERSION="v12" 
        
             - NODE_VERSION="v11" 
        
             - NODE_VERSION="v10" 
        
             - NODE_VERSION="v9" 
        
             - NODE_VERSION="v8" 
        
             - NODE_VERSION="v7" 
        
             - NODE_VERSION="v6"

Adding node 13 (and 14 in may) to this matrix wil cause these additional binaries to be published.

The AWS SDK is used to publish:

fsevents/.travis.yml

Line 44 in 909af26

- npm install aws-sdk

Which uses the API credentials stored here:

fsevents/.travis.yml

Lines 5 to 6 in 909af26

    
           - secure: "gve1nkeKkwFEG1VAT3i+JwYyAdF0gKXwKx0uxbkBTsmm2M+0MDusohQdFLoEIkSIFktXBIDefoa7iGpLKRfG2VsZLpwJgnvnD0HqbnuR+k+W+bu7BHt4CAaR6GTllsDCjyq9zNyhUThzSnf2WNIpOEF5kHspZlbGfawURuUJH/U=" 
        
           - secure: "jqVpmWxxBVXu2X8+XJMpKH0cooc2EKz9xKL2znBfYdNafJORSXcFAVbjCX5mZmVDcgIMwDtm2+gIG4P73hzJ2e3S+y2Z9ROJGyXHa3AxUTvXHQsxqzH8coHHqB8vTvfr0t2O5aKfpvpICpSea39r0hzNoMv6Ie5SwBdqj1YY9K0="

Whether or not binaries should be published is decided upon here:

fsevents/.travis.yml

Line 63 in 909af26

    
           - if [[ $TRAVIS_BRANCH == `git describe --tags --always HEAD` ]]; then PUBLISH_BINARY=true; fi;       # a

Actual publishing is done here:

fsevents/.travis.yml

Line 69 in 909af26

    
           - if [[ $PUBLISH_BINARY == true ]]; then npm run node-pre-gyp package publish; fi;

See the node-pre-gyp docs for more info on setting up the environment:
https://github.com/mapbox/node-pre-gyp#configuring

If you can provide an S3 bucket, I can build you a PR. You / we can then update the secrets in .travis.yml needed to publish to that S3 bucket.

Note: Yes, I know this is only until all dependent packages publish their newer versions with fsevent@2 / chokidar@3

guidobouman · 2020-01-09T15:17:37Z

Sidenote

If you really need npm ci to work on windows environments, you can (temporarily) lock the version in your own dependencies list:

{
  ...
  "optionalDependencies": {
    "fsevents": "1.2.9"
  },
  "_comment": "fsevent@1.2.9 is locked in to prevent broken builds on windows for v1.2.11"
}

This works until the issue is resolved in a more sustainable manner at npm or fsevents.

Do note: This breaks when you run Node v13, as the binaries are not available for that version.

daric81 · 2020-01-16T13:41:18Z

works a treat thanks @guidobouman

KlausHans · 2020-02-18T14:33:28Z

My issue disappeared after the weekend.

yangmingshan · 2020-02-20T15:57:08Z

If you use yarn, selective dependency resolutions may can save you. e.g. webpack:

{
  "resolutions": {
    "webpack-dev-server/chokidar": "^3.3.1",
    "webpack/watchpack/chokidar": "^3.3.1"
  }
}

rabindranathfv · 2020-03-10T13:22:55Z

is this problem just apper into windows CI enviroments? now i am try to build in a CI/CD Linux eviroments and give some similar errors

i am using node 10.5.1, npm 6.0.1 and fsevent 1.2.11 (i was using fsevents 1.2.9 but the same error is used)

ui-dev/node_modules/.staging npm timing stage:rollbackFailedOptional Completed in 412ms npm timing stage:runTopLevelLifecycles Completed in 76478ms npm verb stack Error: Unsupported platform for fsevents@1.2.11: wanted {"name":"fsevents","version":"1.2.11","description":"Native Access to Mac OS-X FSEvents","main":"fsevents.js","dependencies":{"bindings":"^1.5.0","nan":"^2.12.1","node-pre-gyp":"*"},"os":["darwin"],"engines":{"node":">=4.0"},"scripts":{"test":"node ./test/fsevents.js && node ./test/function.js 2> /dev/null","install":"node-gyp rebuild"},"repository":{"type":"git","url":"git+https://github.com/strongloop/fsevents.git"},"keywords":["fsevents","mac"],"author":{"name":"Philipp Dunkel","email":"pip@pipobscure.com"},"license":"MIT","bugs":{"url":"https://github.com/strongloop/fsevents/issues"},"homepage":"https://github.com/strongloop/fsevents","_resolved":"https://npm-registry.fif.tech/fsevents/-/fsevents-1.2.11.tgz","_integrity":"sha512-+ux3lx6peh0BpvY0JebGyZoiR4D+oYzdPZMKJwkZ+sFkNJzpL7tXc/wehS49gUAxg3tmMHPHZkA8JU2rhhgDHw==","_from":"fsevents@1.2.11","gypfile":true,"bundleDependencies":["node-pre-gyp"],"_id":"fsevents@1.2.11","_requested":{"type":"version","registry":true,"raw":"fsevents@1.2.11","name":"fsevents","escapedName":"fsevents","rawSpec":"1.2.11","saveSpec":null,"fetchSpec":"1.2.11"},"_spec":"1.2.11","_where":"/var/tmp/workspace/cmr/cl/apertura/web-ui-dev","_args":[["fsevents@1.2.11","/var/tmp/workspace/cmr/cl/apertura/web-ui-dev"]]} (current: {"os":"linux","cpu":"x64"}) npm verb stack at checkPlatform (/usr/local/lib/node_modules/npm/node_modules/npm-install-checks/index.js:45:14) npm verb stack at tryCatcher (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23) npm verb stack at ret (eval at makeNodePromisifiedEval (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promisify.js:184:12), <anonymous>:13:39) npm verb stack at readJson.then.catch.then (/usr/local/lib/node_modules/npm/lib/install/action/refresh-package-json.js:31:12) npm verb stack at tryCatcher (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/util.js:16:23) npm verb stack at Promise._settlePromiseFromHandler (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:512:31) npm verb stack at Promise._settlePromise (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:569:18) npm verb stack at Promise._settlePromise0 (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:614:10) npm verb stack at Promise._settlePromises (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:693:18) npm verb stack at Promise._fulfill (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:638:18) npm verb stack at Promise._settlePromise (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:582:21) npm verb stack at Promise._settlePromise0 (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:614:10) npm verb stack at Promise._settlePromises (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:693:18) npm verb stack at Promise._fulfill (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:638:18) npm verb stack at Promise._resolveCallback (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:432:57) npm verb stack at Promise._settlePromiseFromHandler (/usr/local/lib/node_modules/npm/node_modules/bluebird/js/release/promise.js:524:17) npm verb pkgid fsevents@1.2.11 npm verb cwd /var/tmp/workspace/cmr/cl/apertura/web-ui-dev npm verb Linux 3.10.0-1062.12.1.el7.x86_64 npm verb argv "/usr/local/bin/node" "/usr/local/bin/npm" "install" "--verbose" "--userconfig=.npmrc" npm verb node v10.5.0 npm verb npm v6.1.0 npm ERR! code EBADPLATFORM npm ERR! notsup Unsupported platform for fsevents@1.2.11: wanted {"os":"darwin","arch":"any"} (current: {"os":"linux","arch":"x64"}) npm ERR! notsup Valid OS: darwin npm ERR! notsup Valid Arch: any npm ERR! notsup Actual OS: linux npm ERR! notsup Actual Arch: x64 npm verb exit [ 1, true ] npm timing npm Completed in 80960ms

i check dependencies with npm list fsevent and another package use lowest version of fsevent like chokidar, any advice?

idanwork · 2020-03-24T07:15:32Z

Just encountered the same issue,
Until it's resolved I have set the command npm ci to ignore errors on windows:

npm ci 2>nul

This allows the build to continue without errors,
It has the risk of other errors not being reported as well, so use if you do the same keep that in mind.

guidobouman · 2020-03-24T11:12:15Z

@idanwork That's a very reckless approach. npm ci was designed to throw an error when the package-lock & package.json are out of sync. If you're willing to give that up: it's better to just use npm i instead. A broken npm ci might silently break your whole build with errors coming from build or test steps that actually originate from the obfuscated failed install.

More info:
npm/cli#558 (comment)

Better yet, use this temporary setup:
#301 (comment)

rajivshah3 · 2020-04-15T20:17:00Z

Can you guys setup a new AWS S3 bucket?

@guidobouman is there a reason S3 needs to be used? Instead the artifacts could be uploaded to the "Releases" page, for example. That would avoid problems with the maintainers losing access to AWS or another service

pipobscure · 2020-04-15T20:33:42Z

Fundamentally v1.x is deprecated. There is no valid reason anyone should use it. Please bug upstream maintainers to upgrade to v2.x which has been available for a year already. Anyone not doing so is a serious threat to security.

guidobouman · 2020-04-16T13:39:02Z

Sure, but implementors like webpack@4 can not upgrade because of breaking semver when upgrading dependencies. So yes, for new versions they can implement the newer version. But for current packages this is often not an option. The intermediate option would be to get chokidar@2 to upgrade to fsevents@2, and release a bug fix. But that's the same issue: breaking semver.

Sorry to be so blunt, but in the end this is all caused by you guys breaking builds & semver support in a patch release.

guidobouman · 2020-04-16T13:40:36Z

@rajivshah3 S3 is used in the old setup, so this is the easiest route to get an old version to work again. For v2 all this is not needed.

pipobscure · 2020-04-16T13:48:11Z

@guidobouman sorry to be so blunt, but this is caused by people neglecting their dependencies. The only difference between chokidar@2 and chokidar@3 is that the latter has an async close method to stop monitoring. This has been an issue for a year now and we’ve been trying to minimise the impact while asking upstream users to upgrade quickly due to security issues. So if webpack (for any value of webpack) can’t be asked to upgrade for a security issue, when there are only miniscule api differences, then they are part of the problem.

guidobouman · 2020-04-16T14:14:11Z

This is not simply a case of neglecting dependencies.

chokidar@3 drops node@6 & node@7:
https://github.com/paulmillr/chokidar/releases/tag/3.0.0

I've pushed the upgrade with the webpack maintainers before:
webpack/watchpack#137

Packages that have supported node@6 before can not upgrade within a patch or minor release. They need a major release to do so.

Yes, node@6 has been EOL for almost a year. But that shouldn't mean that a rebuild of an old build (that used to work) should break suddenly because a package has broken support in a patch release. Supporting new versions of node is a new feature change. Dropping old ones is a breaking change. Neglecting this is the reason semver is not widely trusted, and the need for version locks is required.

And security in front-end packages... This is only ever an issue if external sources get to trigger execution trough those packages with custom content or properties. 99% of usage scenarios are not within this domain. The only case I can think of is online code editors like CodePen. That's why security fixes should always be pushed in patch releases.

Compare this to the ~25% (rough guess) of webpack / watchpack builds that are on Windows, that now all fail with fsevents@1.2.12 as soon as they update a single dependency.

guidobouman · 2020-04-16T14:27:46Z

Don't get me wrong, I want to fix the situation. But every step of the way I am met with resistance. Some resistance is grounded, some is less so.

I would love to write the whole pull request and add support back for the old platforms.

paulmillr · 2020-04-16T16:56:29Z

I've tried setting up builds using your comments (thanks for that), but got nowhere. It's complicated. We're open if someone is able to resolve it.

rajivshah3 · 2020-04-24T18:39:14Z

Until S3 is sorted out, I think this can help in the meantime: #322

pipobscure · 2020-05-05T21:09:47Z

Non-Mac will no longer attempt building since v1.2.13

paulmillr closed this as completed Dec 20, 2019

paulmillr changed the title ~~fsevents 1.2.11 causes npm to set exitcode~~ windows: fsevents v1 is getting built Dec 25, 2019

paulmillr reopened this Dec 25, 2019

paulmillr mentioned this issue Dec 28, 2019

Update chokidar to v3 webpack/webpack-dev-server#2376

Closed

tlmii mentioned this issue Jan 2, 2020

webpack-cli@4.0.0-beta.1 still (transitively) depends on webpack@4.x.x webpack/webpack-cli#1163

Closed

guidobouman mentioned this issue Jan 6, 2020

[BUG] npm ci ignores the os field of package.json npm/cli#658

Closed

ManfredLange mentioned this issue Jan 19, 2020

fsevents installation crashes with "'MSVSProject' object has no attribute 'iteritems'" nodejs/node-gyp#661

Closed

yukukotani mentioned this issue Jan 20, 2020

[Win32] Test Suite Failing on Windows CI FredKSchott/snowpack#151

Closed

paulirwin mentioned this issue Mar 11, 2020

AttributeError: 'MSVSProject' object has no attribute 'items' nodejs/node-gyp#2058

Closed

N6REJ mentioned this issue Mar 12, 2020

[4.0] npm ci not working joomla/joomla-cms#28136

Closed

JohnYoungers mentioned this issue Mar 13, 2020

[BUG] npm ci installs an optional dependency which targets a different os than the host os npm/cli#558

Closed

mattstratton mentioned this issue Mar 17, 2020

[🛠] Package update and asset regenerate devopsdays/devopsdays-web#9647

Merged

mtmtcode mentioned this issue Mar 19, 2020

npm audit reports vulnerabilities webpack/watchpack#149

Closed

devoto13 mentioned this issue Mar 23, 2020

Need to document that it has dependency on Python 2.7 angular/angular-cli#17284

Closed

sr258 mentioned this issue Apr 12, 2020

Outdated dependencies and lock file issues Lumieducation/Lumi#344

Closed

rajivshah3 mentioned this issue Apr 24, 2020

Only build fsevents on macOS #322

Merged

richardlau mentioned this issue May 1, 2020

gyp ERR! configure error during "npm ci" command run nodejs/node-gyp#2110

Closed

pipobscure closed this as completed May 5, 2020

amoerie mentioned this issue May 11, 2020

Update to fsevents 1.2.13 webpack/watchpack#159

Closed

asanchezr mentioned this issue Jun 12, 2020

PIMS-1739 Map clustering bcgov/PIMS#314

Merged

MinusFour mentioned this issue Sep 23, 2020

[feature] Entorno de Desarrollo para rPI elhacker-net/web-nuevo#12

Merged

This was referenced Jan 27, 2021

[KED-2210] Update npm dependencies kedro-org/kedro-viz#360

Merged

[KED-2210] Repeatedly attempt dependency installs on CircleCI kedro-org/kedro-viz#366

Merged

windows: fsevents v1 is getting built #301

windows: fsevents v1 is getting built #301

Comments

aljopro commented Dec 20, 2019 • edited

paulmillr commented Dec 20, 2019 • edited

pelepelin commented Dec 25, 2019

paulmillr commented Dec 25, 2019

paulmillr commented Dec 25, 2019

pelepelin commented Dec 25, 2019

paulmillr commented Dec 25, 2019

aljopro commented Dec 25, 2019 • edited

aljopro commented Dec 25, 2019

ekravtsova commented Dec 26, 2019

seangwright commented Dec 27, 2019 • edited

paulmillr commented Dec 28, 2019

guidobouman commented Jan 6, 2020 • edited

guidobouman commented Jan 7, 2020

paulmillr commented Jan 7, 2020

guidobouman commented Jan 7, 2020

paulmillr commented Jan 8, 2020

guidobouman commented Jan 8, 2020

paulmillr commented Jan 8, 2020

pipobscure commented Jan 8, 2020

guidobouman commented Jan 8, 2020 • edited

guidobouman commented Jan 9, 2020 • edited

Sidenote

daric81 commented Jan 16, 2020

KlausHans commented Feb 18, 2020 • edited

yangmingshan commented Feb 20, 2020

rabindranathfv commented Mar 10, 2020

idanwork commented Mar 24, 2020

guidobouman commented Mar 24, 2020 • edited

rajivshah3 commented Apr 15, 2020

pipobscure commented Apr 15, 2020

guidobouman commented Apr 16, 2020

guidobouman commented Apr 16, 2020 • edited

pipobscure commented Apr 16, 2020

guidobouman commented Apr 16, 2020 • edited

guidobouman commented Apr 16, 2020 • edited

paulmillr commented Apr 16, 2020

rajivshah3 commented Apr 24, 2020

pipobscure commented May 5, 2020

aljopro commented Dec 20, 2019 •

edited

paulmillr commented Dec 20, 2019 •

edited

aljopro commented Dec 25, 2019 •

edited

seangwright commented Dec 27, 2019 •

edited

guidobouman commented Jan 6, 2020 •

edited

guidobouman commented Jan 8, 2020 •

edited

guidobouman commented Jan 9, 2020 •

edited

KlausHans commented Feb 18, 2020 •

edited

guidobouman commented Mar 24, 2020 •

edited

guidobouman commented Apr 16, 2020 •

edited

guidobouman commented Apr 16, 2020 •

edited

guidobouman commented Apr 16, 2020 •

edited