Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Package is broken with node 14 : fs.watch with recursive is throwing on incompatible os #143

Closed
ddavid67 opened this issue Apr 21, 2020 · 21 comments

Comments

@ddavid67
Copy link

ddavid67 commented Apr 21, 2020

Hello,

I just upgraded node to v14 on my fedora 31.
It seems this package is now broken due to this commit : nodejs/node@67e067eb06

Also check updated doc : fs.watch doc

The recursive option is only supported on macOS and Windows. An ERR_FEATURE_UNAVAILABLE_ON_PLATFORM exception will be thrown when the option is used on a platform that does not support it.

Output error example :

# npx ts-node-dev src/main.ts
Using ts-node version 8.4.1, typescript version 3.8.3
TypeError [ERR_FEATURE_UNAVAILABLE_ON_PLATFORM]: The feature watch recursively is unavailable on the current platform, which is being used to run Node.js
    at Object.watch (fs.js:1441:11)
    at add (/root/backend/node_modules/filewatcher/index.js:74:34)
    at /root/backend/node_modules/filewatcher/index.js:93:5
    at FSReqCallback.oncomplete (fs.js:176:5)

Using recursive: true now throws an Error that is not handled.
https://github.com/whitecolor/ts-node-dev/blob/c0df64c43455d2f8ef144eb9defcd05b6fc52486/lib/index.js#L45

@ddavid67 ddavid67 changed the title Package is broken with node 14 : fs.watch is now throwing on incompatible os Package is broken with node 14 : fs.watch with recursive is throwing on incompatible os Apr 22, 2020
JVictorV added a commit to JVictorV/orangedit that referenced this issue Apr 24, 2020
@ftzi
Copy link

ftzi commented Apr 24, 2020

Same issue here. Thanks for pointing out that the problem is caused by the Node v14. Would never figure out.

@Leko
Copy link

Leko commented Apr 29, 2020

@whitecolor I think we can fix this issue by migrating to chokidar instead of fs.watch. Does it make sense?

@desmap
Copy link

desmap commented May 2, 2020

facing the same problem

@kiprasmel
Copy link

kiprasmel commented May 9, 2020

Bump - just updated to node v14 and got the same issue. Downgrading to v13 or lower works just fine.
(I recommend using https://github.com/tj/n or https://github.com/nvm-sh/nvm)

Edit: It seems like ts-node had a similar issue a while ago? nodejs/node#20258

@McSneaky
Copy link

McSneaky commented May 22, 2020

Problem is in underlying filewatcher issue is already raised in there and PR made

Thnx for @onlurking for making fix for it

But it seems like filewatcher has not been updated for a while tho, so not sure if it will get merged in there 😞

@marcoreni
Copy link

Maybe this project should migrate to chokidar:

Node.js fs.watch:
* Doesn't report filenames on MacOS.
* Doesn't report events at all when using editors like Sublime on MacOS.
* Often reports events twice.
* Emits most changes as rename.
* Does not provide an easy way to recursively watch file trees.

Node.js fs.watchFile:
* Almost as bad at event handling.
* Also does not provide any recursive watching.
* Results in high CPU utilization.

Chokidar resolves these problems.

@wclr
Copy link
Owner

wclr commented May 22, 2020

Will check everything and release it with chokidar soon.

@kachkaev
Copy link

@whitecolor if you are planning to release a new ×.−.− or −.×.− version, will be happy to also accept a PR that adds #136? I can do it if there is a probability of acceptance 🙂

@bobbui
Copy link

bobbui commented May 27, 2020

looking forward to the release, right now i'm using a temporary setup with pure nodemon and ts-dev which is at least twice slower to restart

mmvsk pushed a commit to mmvsk/ts-node-dev that referenced this issue May 28, 2020
@mmvsk
Copy link

mmvsk commented May 28, 2020

Hey, while waiting for a fix in filewatcher or here, I just made a quick & dirty fix by disabling the recursive option on Linux and Node 14, to be able to use ts-node-dev right now in this environment.

To select this specific commit:

npm add -D 'mmvsk/ts-node-dev#d7e9cfbad414bcc5fc9ddb5cf75a74496a9e4549'

@ssomlk
Copy link

ssomlk commented May 28, 2020

I am getting this error when using node:alpine when using Docker.
Suppose I need to downgrade the Node version how can I do it in the Docker file.

SInce I am new to docker would appreciate if someone can assist

@marcoreni
Copy link

marcoreni commented May 28, 2020

@ssomlk you should node:13-alpine if you want to use Node 13 instead of latest.

Here you can find a list of all the released tags: https://hub.docker.com/_/node/
I think that Docker has a Get Started guide that may help you with these basic concepts.

@ssomlk
Copy link

ssomlk commented May 28, 2020

Thanks alot and apreciate ur help @marcoreni

@ghost
Copy link

ghost commented May 29, 2020

Run using ts-node-dev --poll src/index.ts

@mpcen
Copy link

mpcen commented May 31, 2020

using node v13.14.0 until the fix is merged and works fine

@DonIsaac
Copy link

DonIsaac commented Jun 2, 2020

@mmvsk That fix is pretty nifty, have you submitted it as a pull request yet?

@mmvsk
Copy link

mmvsk commented Jun 3, 2020

@mmvsk That fix is pretty nifty, have you submitted it as a pull request yet?

I just did in PR #149. I'm using ts-node-dev with this fix and everything works just fine (including in deep subdirectories).

For those who want to use this fix right now, before the PR is merged or the underlying issue solved in some other way, you can just install the patched version from my repository:

npm add -D 'mmvsk/ts-node-dev#d7e9cfbad414bcc5fc9ddb5cf75a74496a9e4549'

(and later reinstall the official one, once it's fixed)

@loreanvictor
Copy link

@mmvsk doesn't your PR simply disable recursive watching on linux / node 14? or would it work on linux machines with recursive watching as well (and I am mis-understanding something)?

P.S. perhaps using something like this (or another alternative fs.watch wrapper, I don't know which of these packages actually solves this issue and is performant/reliable enough) would alleviate the issue?

@mmvsk
Copy link

mmvsk commented Jun 7, 2020

@mmvsk doesn't your PR simply disable recursive watching on linux / node 14? or would it work on linux machines with recursive watching as well (and I am mis-understanding something)?

P.S. perhaps using something like this (or another alternative fs.watch wrapper, I don't know which of these packages actually solves this issue and is performant/reliable enough) would alleviate the issue?

Yes, it's precisely what it does. But actually the recursive option never worked on Linux: before Node 14 fs-watch was silently failing, and now it raise an error. So this PR is basically reverting ts-node-dev to its original behavior.

Actually it "works" on Linux in the same way it was working before Node 14: by using the dependency chain built by the imports. So it's possible to have some missed detections if a file is modified in a deep directory without being imported anywhere - in the exact same way as in Node 13 and before - but in most cases it will work just fine.

And I agree with you: ideally, fs-watch should be replaced and node-watch seems like a good candidate for that, better than chokidar that was proposed earlier in this thread.

tl;dr

@wclr
Copy link
Owner

wclr commented Jun 13, 2020

Replaced with chokidar in the latest published.

@wclr wclr closed this as completed Jun 13, 2020
@danielkcz
Copy link

Thank you for the fix. Had the same issue on Windows and WSL2 and the latest pre.49 works nicely.

LachlanStuart added a commit to metaspace2020/metaspace that referenced this issue Jul 15, 2020
Update webapp babel (via manual lockfile deletion & reinstall) due to babel/babel#11216
Update webapp node-sass for Node 14 support
Update webapp element-ui due to ElemeFE/element#19389
Update graphql bcrypt to hopefully fix rebuild-on-node-version-change behavior
Update graphql knex/pg to fix knex/knex#3836
Update graphql winston to fix winstonjs/winston#1797
Update graphql ts-node-dev to fix wclr/ts-node-dev#143
Pin version of graphql graphql-binding because I remember newer versions not being compatible

Remove hacks needed for node 8 (asyncIterator polyfill, incorrect date format in ElapsedTime.spec.ts)
Updated FilterPanel snapshot. It seems the reason it was reordered was because Array.prototype.sort started using a stable sorting algorithm in Node 11, and `sortFilterKeys` in store/mutations.js sorts against the same value for most items.
LachlanStuart added a commit to metaspace2020/metaspace that referenced this issue Jul 27, 2020
* Upgrade node to v14
Update webapp babel (via manual lockfile deletion & reinstall) due to babel/babel#11216
Update webapp node-sass for Node 14 support
Update webapp element-ui due to ElemeFE/element#19389
Update graphql bcrypt to hopefully fix rebuild-on-node-version-change behavior
Update graphql knex/pg to fix knex/knex#3836
Update graphql winston to fix winstonjs/winston#1797
Update graphql ts-node-dev to fix wclr/ts-node-dev#143
Pin version of graphql graphql-binding because I remember newer versions not being compatible

Remove hacks needed for node 8 (asyncIterator polyfill, incorrect date format in ElapsedTime.spec.ts)
Updated FilterPanel snapshot. It seems the reason it was reordered was because Array.prototype.sort started using a stable sorting algorithm in Node 11, and `sortFilterKeys` in store/mutations.js sorts against the same value for most items.

* Re-enable supervisorctl autorestart

* Debug logging about node versions

* Ansible fixes

* Fix use of nvm in Ansible/Supervisor

* Update CircleCI image for Node 14

* Update graphql lockfile

* Update suggested fix for missing DB schema during provision

* Re-disable sm-cluster-autostart-daemon autorestart

* Make "sm_activate_nvm" variable to simplify nvm use

* Fix after merge
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests