Build binary for Node 11

[billyjanitsch]

Node 11 was released in October. There does not yet exist a prebuilt fsevents binary.

[AdamModus]

I feel you! I have felt the same issue 😅

[pipobscure]

I'll be releasing the NAPI version over XMas. From then on no specific version builds will be required. Can we hold for that (as I don't have a current build setup that can publish binaries?)

[AdamModus]

I've been keeping my node version at 10 so I've been okay with this so far and have no actual serious problems. But out of curiosity: have there been any developments on this? :)

[tarelli]

Any update about this?

node-pre-gyp WARN Tried to download(404): https://fsevents-binaries.s3-us-west-2.amazonaws.com/v1.2.4/fse-v1.2.4-node-v67-darwin-x64.tar.gz

Building from sources not working.

[bnoordhuis]

I suppose we could publish a new v1.x release so that binaries for Node.js 11 are available?

I think it's just a matter of branching at commit 4c48d82 and adding Node.js 11 to .travis.yml. Good idea, bad idea?

cc @es128 @pipobscure

[SimenB]

Sorta related, will it be possible to build from source for node 12 (it doesn't compile)? Making a pre-built binary months before 12 is released is probably not necessary :P. I wanted to test the nightly in Jest, and we have some noisy watch-mode tests that fail since fsevents is missing.

[pipobscure]

Just release v1.2.6 which has node-v11 binaries.

Regarding v12, by the time that get's cut in October. The NAPI version will be out and supported by chokidar. I'm also working on notifying all dependents of the upcoming change. So we won't be supporting v1.x under node-v12+.

[SimenB]

v12 will come in April. Seems unfortunate to not have any overlap between the outgoing maintanance LTS and the incoming one. Forces quite a lot of libraries to drop node < 8 instantly, and coordinate major releases with fsevents

[pipobscure]

@SimenB

Let's see what happens. The issue is that fsevents@1.x doesn't currently compile under v12 because v8 has moved too far ahead. If it's an easy fix I might be convinced.

However as it stands I'm actually planning to send an email to the maintainers of all dependants asking them to update, giving them a shim if needed.

Truth be told, if you are currently running node < 6 (and node < 8 as of April), that's a problem as by then you'll get 0 security updates.

Also for the specific case of fsevents: I think it's likely less of an issue, since it's a Mac-OSX only package. That means it'll be installed 99.9999% on developer machines. Plus the dependant packages (if they want to support non-Mac platforms) have to have it as an optional dependency anyhow. So most will fallback to some other behaviour if fsevents does not load. In that case that fallback would work for MacOSX as well (albeit less performant / smooth). So for this case, I think it's not really a problem.

The main dependent (chokidar), will get the update asap. There it the call of @paulmillr on how to proceed. But I'm guessing that falling back to the current fallback (polling) will be fine there as well.

[paulmillr]

The main thing for chokidar is to have great user experience. This needs some testing, but would probably help a lot. I'm totally in favor of requiring node 8+ for it, since v6 won't get security updates as @pipobscure mentioned — and because older chokidar versions would still work if you need support for node 0.12 etc.