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

On Windows, a change event is fired after an add event when a file is created #1332

Closed
valadaptive opened this issue Jun 27, 2024 · 1 comment

Comments

@valadaptive
Copy link

valadaptive commented Jun 27, 2024

Versions (please complete the following information):

  • Chokidar version: 3.6.0 and v4 beta (v4 branch)
  • Node version: v20.15.0
  • OS version: Windows 10 (built 19045)

To Reproduce:

On a Windows system, run .\node_modules\.bin\mocha -g "previously deleted" (for v3) or node --test --test-name-pattern "previously deleted" (for v4) to run a test which expects change events to not be fired. You may need to run it quite a few times.

Here's a test case for the v4 node --test setup:

    it('should not emit `change` events for added files', async () => {
      const addSpy = sinon.spy(function add(){});
      const changeSpy = sinon.spy(function change(){});
      const testPath = getFixturePath('add.txt');
      watcher
        .on(EV.ADD, addSpy)
        .on(EV.CHANGE, changeSpy);
      await write(testPath, 'hello');
      await waitFor([[addSpy.withArgs(testPath), 1]]);
      changeSpy.should.not.have.been.called;
    });

Expected behavior
The change event should not be fired. Chokidar already deduplicates successive change events that happen within 5ms of each other, but does not deduplicate change requests that happen within 5ms of an add event.

Additional context
This seems to be causing the test failure in #1329. I can only guess that it's not failing in the current branches because of some complex timing conditions or just because it got very lucky.

@valadaptive
Copy link
Author

Ah, looks like this is already implemented as awaitWriteFinish. Maybe it's worth defaulting it to true in the next major release and adjusting the timing?

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

2 participants