Gatsby: How to Enable Resource-Responsible Polling for When inotify Won't Work

[IMBurbank]

It's a known issue on Docker for Windows that inotify does not work on shared volumes. This means that running gatsby develop in a docker container and editing the files locally will not trigger webpack-dev-server updates.

I came across this issue while working on GatsD, a lightweight tool to develop Gatsby with all the dependencies in a docker container. But this problem is common to everyone who wants to use docker to develop Gatsby projects on a Windows machine.

I generally consider this a Docker/Windows issue, but I'm hoping someone here who's worked on the dev-server setting might know a fairly resource-responsible polling setting (or better solution) that could be added the the gatsby-node.js webpack config.

The Docker site mentions a workaround for nodemon users- switching to their fallback legacy polling mode. I think a good polling setup could provide users a useful fallback compatibility option while keeping Gatsby out of the Windows-filesystem-event muck.

Essentially:
How can I set up a workable fallback solution for dev environments that can't count on inotify events?

[pieh]

I thinkg we need to use CHOKIDAR_USEPOLLING env var here - also see https://www.npmjs.com/package/chokidar#performance for implication of that

[IMBurbank]

Thank you for the quick response, @pieh

I read what I could about find about chokidar with Gatsby, including #3043.

I tried the simplest implementation - exporting CHOKIDAR_USEPOLLING=1 into the dev environment. But it didn't seem to start the polling.

What's the best way to set the chokidar options in a Gatsby project?

So far in my fiddling, I've only gotten it to work by adding chokidar options to files I should never touch in node_modules/gatsby/dist/.

node_module/gatsby/dist/commands/develop.js

    ...
    const watchGlobs = [`src/html.js`, `plugins/**/gatsby-ssr.js`].map(path => slash(directoryPath(path)));
    chokidar.watch(watchGlobs, {
      usePolling: true,
      interval: 100,
      binaryInterval: 300,
      awaitWriteFinish: {
        stabilityThreshold: 2000,
        pollInterval: 100
      },   
    }).on(`change`,
    /*#__PURE__*/
    (0, _asyncToGenerator2.default)(function* () {
      yield createIndexHtml();
      socket.to(`clients`).emit(`reload`);
    }));
    ...

node_module/gatsby/dist/internal-plugins/dev-404-page/gatsbt-node.js

    ...
    chokidar.watch(source, {
      usePolling: true,
      interval: 100,
      binaryInterval: 300,
      awaitWriteFinish: {
        stabilityThreshold: 2000,
        pollInterval: 100
      },   
    }).on(`change`, () => copy()).on(`ready`, () => done());
    ...

Of course, I need to set the chokidar dev config in my own project files - I imagine in gatsby-node.js.

[pieh]

Would running CHOKIDAR_USEPOLLING=1 gatsby develop work? I must say I didn't try it, just something I remember was used and reported to work

[IMBurbank]

Adding the env variable to the run line definitely works, thank you!

Do you know where I can set the polling config to cut down on resources (that doesn't involve breaking in to node_modules)?

[pieh]

From the same link - https://www.npmjs.com/package/chokidar#performance

You may also set the CHOKIDAR_INTERVAL env variable to override this option.
so at least interval can be configured via env var as well it seems

[IMBurbank]

The interval can be overridden with an env variable, but it's the only setting that can be. I was hoping to fine-tune the polling a bit for windows users as they're likely the primary ones to need it.

[IMBurbank]

If there's not a way set Gatsby's chokidar settings, beyond the one env setting, I'll leave it at that... I know you guys are working on a lot - and I primarily do my dev on a linux machine.

I may have missed it in the docs, but this limitation may be worth mentioning.

In any case, thank you very much for looking into this.

[pieh]

The interval can be overridden with an env variable, but it's the only setting that can be. I was hoping to fine-tune the polling a bit for windows users as they're likely the primary ones to need it.

But windows doesn't need polling (I think)?

--edit
Ah you mean docker on windows - my bad

[pieh]

But adding info about those env vars would be useful for sure - docker needs it and also some build servers will need it when there is low inotify watchers limit

[gatsbot[bot]]

Old issues will be closed after 30 days of inactivity. This issue has been quiet for 20 days and is being marked as stale. Reply here or add the label "not stale" to keep this issue open!

[gatsbot[bot]]

Hey again!

It’s been 30 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.

Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to reopen this issue or create a new one if you need anything else.

Thanks again for being part of the Gatsby community!