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

A better workaround for atomic writes #791

Merged
merged 2 commits into from
Mar 7, 2019

Conversation

mitar
Copy link
Contributor

@mitar mitar commented Feb 8, 2019

This fixes #742 and fixes #237.

@coveralls
Copy link

coveralls commented Feb 8, 2019

Coverage Status

Coverage increased (+0.4%) to 96.62% when pulling 8d33e01 on mitar:atomic-workaround into c7cf6e9 on paulmillr:master.

@coveralls
Copy link

Coverage Status

Coverage increased (+0.4%) to 96.62% when pulling 4a3db5a on mitar:atomic-workaround into c7cf6e9 on paulmillr:master.

@SGrondin
Copy link

SGrondin commented Mar 7, 2019

Posting here to confirm that this PR fixed our issues in Parcel.

@paulmillr
Copy link
Owner

@SGrondin fixed issues in Parcel and broke in Gatsby...

@cmcaine
Copy link

cmcaine commented May 28, 2019

@paulmillr do you have any ideas for how to fix this without breaking other tools? It's unclear to me why gatsby failed...

I might even have the time to do a PR ;)

Refs:
gatsbyjs/gatsby#12759
parcel-bundler/parcel#221

In the meantime #742 and #237 should probably be re-opened, right?

@wpyoga
Copy link

wpyoga commented Aug 1, 2021

Hello. I noticed a problem with docusaurus a few days ago, and traced it back to this apparent problem in chokidar. This is the issue: facebook/docusaurus#5252 . I've set up a repo to reproduce the issue: wpyoga/repro-docusaurus-5252, hopefully that can help to diagnose the problem. I've only tried it on my Linux laptop though.

The problem manifests itself in this way: when I run the docusaurus development server, and then make changes to its config file docusaurus.config.js using vim, only the first change will trigger a rebuild of the site. Further changes wouldn't. Also, other editors including nano and VS Code don't trigger this issue.

Based on my experiments, what I think happened was:

  1. When vim saves a file, it will write the data to a temporary file, then remove the original file, and then replace the original file with the temporary file.
  2. This setTimeout()'s callback runs before the delay value passed into setTimeout(): https://github.com/paulmillr/chokidar/blob/master/index.js#L579-L585 . This caused the file to be removed from the watch list, so further changes to the file does not trigger an event.
  3. I was able to reproduce this in my repo.
  4. Outside of chokidar, I could not make setTimeout() execute its callback before the delay specified.

Since this is actually a PR, should I post this on an issue somewhere? Maybe on #742? (but that issue has been closed)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
6 participants