Nodemon does not reload on --watch folder only on the app file

[MrDesjardins]

• nodemon -v: 1.18.10
• node -v: 10.8.0
• Operating system/terminal environment: MacOS, bash command
• Using Docker? What image: No
• Command you ran: nodemon --watch ./build/dist --watch ./build/dist/graphql/schemas build/dist/index.js -V

Expected behavior

To have NodeJS restart.

Actual behavior

It detects the folder has a file that has changed but does not restart.

Steps to reproduce

1. NPM script:

"watchgraphql": "cpx 'src/graphql/schemas/**/*.graphql' build/dist/graphql/schemas/ -w -v",
"dev": "concurrently \"tsc -w\" \"npm run watchgraphql\" \"nodemon --watch ./build/dist --watch ./build/dist/graphql/schemas build/dist/index.js -V\"",

2. Run the script

npm run dev

This check for TypeScript file, when something is saved, transpile and save the JS. This change the index.js thus node is restarting as expected. However, if I change a .graphql file, the watchgraphql copy the file (as expected) and nodemon detect the change (see the verbose output) but node does not restart.

Verbose output:

[1] Copied: src/graphql/schemas/ocadmin/org.graphql --> build/dist/graphql/schemas/ocadmin/org.graphql
[2] [nodemon] files triggering change check: build/dist/graphql/schemas/ocadmin/org.graphql
[2] [nodemon] matched rule: /Users/pdesjardins/code/ocgraphqlserver/build/dist/graphql/schemas//*
[2] [nodemon] changes after filters (before/after): 1/0
[2] [nodemon] files triggering change check: build/dist/graphql/schemas/ocadmin/org.graphql
[2] [nodemon] matched rule: /Users/pdesjardins/code/ocgraphqlserver/build/dist/graphql/schemas//*
[2] [nodemon] changes after filters (before/after): 1/0
[2] [nodemon] files triggering change check: build/dist/graphql/schemas/ocadmin/org.graphql
[2] [nodemon] matched rule: /Users/pdesjardins/code/ocgraphqlserver/build/dist/graphql/schemas/**/*
[2] [nodemon] changes after filters (before/after): 1/0

[zhylmzr]

same problem.
I found that the change of typescript file doesn't cause a restart.

[zhylmzr]

same problem.
I found that the change of typescript file doesn't cause a restart.

I'm sorry that ignore the specifying extension flag.

[remy]

Can you provide some pared down code to replicate? Otherwise I can't help…sorry.

[bleadof]

Ehlo peeps! I encountered similar problems, so I made a repo https://github.com/bleadof/nodemon-ts-bug.

git clone https://github.com/bleadof/nodemon-ts-bug.git
yarn install
yarn start

Edit src/hello-world.ts

[bleadof]

Ah, it's not a bug, but a feature!

npx nodemon --watch . --watch src --exec yarn run run
[nodemon] 1.18.10
[nodemon] to restart at any time, enter `rs`
[nodemon] watching: *.* /Users/tarmo/Documents/code/js/nodemon-ts-bug/src/**/*
[nodemon] starting `yarn run run`
yarn run v1.13.0
$ babel-node --extensions ".ts" src/hello-world.ts
Hello world
No update on comment remove and save.
✨  Done in 0.76s.
[nodemon] clean exit - waiting for changes before restart

should probably still print the extension so it's less confusing:

npx nodemon --watch . --watch src --exec yarn run run
[nodemon] 1.18.10
[nodemon] to restart at any time, enter `rs`
[nodemon] watching: *.* /Users/tarmo/Documents/code/js/nodemon-ts-bug/src/**/*
[nodemon] watching extensions: js,mjs,json
[nodemon] starting `yarn run run`
yarn run v1.13.0
$ babel-node --extensions ".ts" src/hello-world.ts
Hello world
No update on comment remove and save.
✨  Done in 0.76s.
[nodemon] clean exit - waiting for changes before restart

Made a PR #1537

[stale]

This issue has been automatically marked as idle and stale because it hasn't had any recent activity. It will be automtically closed if no further activity occurs. If you think this is wrong, or the problem still persists, just pop a reply in the comments and @remy will (try!) to follow up.
Thank you for contributing <3

[webextensions]

@MrDesjardins @remy
I was also facing this issue just now. But it turned out to be an issue due to a buggy Chokidar version. Chokidar 2.1.4 was buggy while after 2.1.5, it worked fine.

It appears that paulmillr/chokidar@b79120b fixed it for me (a recent change by @paulmillr). Probably in your case also, it happened due to this or some other buggy dependency package.

If anyone else is facing similar issue, I would recommend to update package-lock.json (delete that file and run npm install) and then try this.

[stale]

This issue has been automatically marked as idle and stale because it hasn't had any recent activity. It will be automtically closed if no further activity occurs. If you think this is wrong, or the problem still persists, just pop a reply in the comments and @remy will (try!) to follow up.
Thank you for contributing <3

[bantic]

I ran into the same problem when using nodemon to watch a directory containing typescript (.ts) files. If I pass the directory to --watch, nodemon doesn't re-exec my script when one of the typescript files is changed.
It was hard to figure this out because even with the --verbose flag on, nodemon doesn't print out the extensions it is matching on.

Example:

// Directory structure:
.
└── src
    └── typescript
        └── index.ts

Run nodemon, watching src/typescript:

$ nodemon --verbose --watch src/typescript -x "echo '--> got change'"
[nodemon] 1.19.1
[nodemon] to restart at any time, enter `rs`
[nodemon] or send SIGHUP to 5438 to restart
[nodemon] watching: /private/tmp/nodemon-example/src/typescript/**/*
[nodemon] watching extensions: js,mjs,json
[nodemon] starting `echo '--> got change'`
[nodemon] spawning
[nodemon] child pid: 5440
--> got change
[nodemon] clean exit - waiting for changes before restart
[nodemon] watching 1 file

//---  in separate terminal run command:  touch src/typescript/index.ts  --- //

[nodemon] files triggering change check: src/typescript/index.ts
[nodemon] matched rule: /private/tmp/nodemon-example/src/typescript/**/*
[nodemon] changes after filters (before/after): 1/0

I found this confusing because in verbose mode nodemon clearly saw that index.ts changed, and it reports that the file matched a rule, so I didn't understand why it didn't result in re-executing my script.

However, as noted by @bleadof above (#1528 (comment)), internally nodemon is filtering out the matched file because its extension .ts isn't one of the default extensions.
I noticed just now that the readme and nodemon --help do indeed mention that there are default extensions:

By default, nodemon looks for files with the .js, .mjs, .coffee, .litcoffee, and .json extensions.

I would add a vote to modify the nodemon output to have it report which extensions it is watching (#1537), or add those to the verbose output. Or, perhaps typescript is popular enough that it could be promoted to one of the default extensions?

[blaasvaer]

So, isn't this the classic answer when you do not get what you EXPECT – it's a feature? But what if I didn't EXPECT it to be a feature? What do we EXPECT from nodemon when using it? And that's what it should be doing. So, when I do:

nodemon --watch . debug.js 9000

I would EXPECT nodemon to watch ANY changes in the dir it is runs from ('./) from users perspective. Now, IF I'm NOT SUPPOSED to do this, then prevent the user from doing it.

Otherwise ... give some meaningful feedback – from a USERs perspective.

So, now I have to spend my saturday messing around with some other dudes 'app' bugs ... sad.

So, HOW do I add file extentions to the config file ( in my case I use the package.json ) but I see no example of getting the -e flag into the config. I only see 'ignore' property ... am I missing something in the docs?

[blaasvaer]

From the docs I can make no sense of how to add a nodemon config to my package.json ... getting all sorts of syntax errors. Please, provide a COMPLETE example – as in a simulated 'real' package.json file ...

OK, after fucking around with this ... I managed to get it to watch .hbs files by adding it to the config. BUT, now it stopped watching all the defaults ... so because I want it to watch ONE special extension I have to add all the defaults manually as well ... !? It that's the case ... I'll guess I have to look for some other tool. That's to counter intuitive ...

[arizonatribe]

Is there a reason so many of these kinds of issues get opened for Nodemon, but not much more than "Please provide me a link to an app" gets done to troubleshoot? How does that get flagged for closing the issue when no real attempt was made to resolve the issue that many people are reporting?

[remy]

@arizonatribe I wonder this too. I mean, you for example took the time to comment (not really adding anything), but haven't attempted a fix or PR. I know exactly what you mean.

[arizonatribe]

Ouch. So when people have asked for help in threads like these you fall silent after looking at a sample app and let stalebot close it down, but when the package itself gets a critique you jump back in just to get defensive? Now that's ego.

Fixing every issue isn't your responsibility - especially for a package as widely used as this one - but you're definitely responsible for communication. If you're bogged down just indicate you're swamped and it'll take time. If you feel a particular issue is something that your average user should be able to take a crack at, challenge them to get involved and invite them into your community of contributors. If you have some proven contributors that are capable of the really challenging issues, maybe ask them to jump in and help. Maybe even use labeling to indicate where the issue is on the roadmap.

People won't be able to read your thoughts or intuit
the protocol and guidelines for your package. Many package authors don't want assistance at all (the author of Hapi JS just posted a very frustrated, half-immature rant yesterday - extremely similar to Franz Kafka's Poseidon character from his short story - chewing out three contributors for doing the things contributors do: submit PRs and make suggestions on how to improve his package). But some package authors do want assistance and genuinely want people to feel community ownership and share responsibility for something they started.

The way you've handled this and the handful of threads I've read through on this ongoing issue are consistently the same though: snippy scolding tone when someone forgets to follow protocol (like creating a link to an app for you to reproduce their error), and on several threads you tend to stop responding altogether and let the stalebot close it. No letting them know you couldn't figure it out or other things came up and labeling the issue for some future spot on the package's roadmap.

This is a great package and you do great work, but you've also fully earned this critique and I challenge you to communicate your intentions, protocol and level of desired involvement better than you're doing.

[paras20xx]

@arizonatribe
Would your concern be resolved to a good enough extent for now by increasing the duration for considering "stale"?

Just proposing it to project collaborator(s) as a time saver to handle any avoidable debates / arguments ... so that the same time can rather be spent on building better things :-)

[remy]

Happy to extend the bots stale period, but the core of the problem is that most issues don't come with PRs, mostly because they're extremely bespoke. And then the issue is autoclosed as stale either way.

I'll reopen this issue if there's a PR to fix it. It obviously matters to some people, but I've not personally had any experience so I don't see this issue in my day to day dev.

[remy]

@arizonatribe sorry chap, I've not really followed your reply. But I do figure it took some time to write, which if this problem affects you, you could have had a go at solving it.

If anyone wants to contribute to fix issues, the project is always very grateful.

[arizonatribe]

Yeah it's 2019: if there's more than two paragraphs and no TLDR; section then it doesn't get read. I doubt it's because it's written in a way that is hard to follow though.

Since this isn't the first, second or even third nodemon thread related to this issue (and the second that's gotten closed by stalebot despite multiple "here here! That's happening to me too. Anyone know why?") changing the stalebot threshold would probably help.

In my case, I think the issue was harder to solve because there were orphaned nodejs file watches triggered by nodemon in the day(s) prior, and I'm not sure why. Not a likely issue to occur for machines that get shutdown and restarted daily, but for an "always up" Linux server that I'm SSH'ing into, non-graceful shutdowns can cause weird side effects after days of continuous use.

[remy]

It's more that I'm not super keen on spending time getting wound up by your reply during the weekend (or the weekdays if I'm honest). Anyway, from what I've determined from your latest comment on the issue, is that in your particular situation, you *think* it's hard to solve, so you don't (I'm guessing) want to try to debug and fix (understandably because it's hard to debug and get tests passing and to actually ensure the original issue has been addressed in a way you can confirm - this is frustratingly a unique aspect of nodemon). Which is probably the same reason no one else has ever taken a shot at it (you mention this has been raised again and again). But sure, it's left to me. I'll attack this issue when it affects me. During my day to day dev I've not encountered this (because my workflow is different), but the day it's a problem, I'll consider (and likely) raise a PR against nodemon to get it fixed. Of course, again, if there's a PR for this, you all guessed right, I'll happily merge. Goodnight folks. Going back my family. Have a good (or better) weekend.

…

On Sat, 28 Sep 2019, 18:42 David Nunez, ***@***.***> wrote: Yeah it's 2019: if there's more than two paragraphs and no *TLDR;* section then it doesn't get read. I doubt it's because it's written in a way that is hard to follow though. Since this isn't the first, second or even third nodemon thread related to this issue (and the second that's gotten closed by stalebot despite multiple "here here! That's happening to me too. Anyone know why?") changing the stalebot threshold would probably help. In my case, I think the issue was harder to solve because there were orphaned nodejs file watches triggered by nodemon in the day(s) prior, and I'm not sure why. Not a likely issue to occur for machines that get shutdown and restarted daily, but for an "always up" Linux server that I'm SSH'ing into, non-graceful shutdowns can cause weird side effects after days of continuous use. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1528?email_source=notifications&email_token=AAADLBGSCPEOSYZC4WP2RHTQL6JR7A5CNFSM4GXSQ4A2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD726WQQ#issuecomment-536210242>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAADLBBFC3GKZ3XG3OQFF4DQL6JR7ANCNFSM4GXSQ4AQ> .

[felippe-regazio]

for those still struggling with nodemon + ts files, im using nodemon 1.19.4, and created this configuration file:

{
  "verbose": true,
  "ext": "ts, js, jsx, tsx, json",
  "ignore": [
    ".git",
    "node_modules/**/node_modules"
  ],
  "events": {
    "restart": "npm run lint; echo '\nRecompiling...\n'; npm run compile; echo '\nReady!\n'"
  },
  "watch": [
    "src"
  ],
  "env": {
    "NODE_ENV": "development"
  }
}