"Gracefully shutting down. To force exit, press ^C again. Please wait…" takes several seconds

[fregante]

Not strictly a bug but I'd like to understand why it's taking 9 seconds to stop processes. From what I understand the log was added (#4145) to avoid FS corruption during builds/writes, but this happens when Webpack is idling (confirmed by --progress)

This is my watch config

  watchOptions: {
    aggregateTimeout: 200,
  },

This brings it down to 1.5 seconds

  watchOptions: {
    aggregateTimeout: 200,
+   ignored: /node_modules/,
  },

This makes nearly instant (probably 0.3s):

    watchOptions: {
      aggregateTimeout: 200,
      ignored: /node_modules/,
+     poll: 300,
    },

I was unable to find any debugging options, so my questions are:

• what's delaying the closure exactly?
• can this perf be improved without using poll?
• what are the consequences of using poll vs not using it?

[alexander-akait]

what's delaying the closure exactly?

Due to this - webpack/watchpack#222, you can faced with the same problems on other OSs too, unfortunate we can't fix it on our side

can this perf be improved without using poll?

No, it is not on our side

what are the consequences of using poll vs not using it?

Depends on OSs, but in most cases the response to changes (file changes) is a bit slow

this happens when Webpack is idling

What do you mean? In regular builds? If yes we have - we have #3075, just need to rebase

[fregante]

What do you mean? In regular builds?

The issue only affects watch mode.

I mean from the last PR description it sounded like the delay only happens while webpack is in the process of building files, but in my case it happens on every ctrl-c regardless of status.

[fregante]

What do you mean? In regular builds? If yes we have - we have #3075, just need to rebase

Oh so probably if I just update watchpack it will work since I have:

  └─┬ webpack@5.99.9
    └── watchpack@2.4.1

[alexander-akait]

I mean from the last PR description it sounded like the delay only happens while webpack is in the process of building files, but in my case it happens on every ctrl-c regardless of status.

Please create reproducible test repo, it should not corrupt caches when you have progress, extra CTRL + C after message can break your caches

[fregante]

You're misunderstanding me, I didn't say it breaks the cache. Disregard that last message, there's nothing to repro.

[alexander-akait]

@fregante So we can close this issue?

[fregante]

I haven't verified if the latest version of watchpack fixed the issue without poll

[alexander-akait]

I will close, when you verify it feel free to post feedback here, we can't control how long OS closes watchers

[fregante]

Do you have to await them? Can't those processes be detached so I don't have to literally wait 9 seconds to use my CLI? I also have Jest watching my FS and exiting is is immediate.

[alexander-akait]

@fregante We should close the watchers to avoid corrupted files and caches, because jest doesn't store them in memory to cache them, there is only one cache for jest - transformation, but it doesn't require to store something in memory and keep open, also you can have two/three/four programs which can open your files, agree, it doesn't happen with node_modules often, but anyway we should use the valid logic here

I can't provide more information without OS information, Node.js information and your configuration, also will be good to see how you run your builds (i.e. CLI command like you have in package.json or what you write in your console).

[fregante]

We should close the watchers to avoid corrupted files

Again, I did not say you should force them to close or leave them open. I just said you don't have to await them before terminating webpack-cli itself. Just call .unref() https://nodejs.org/api/fs.html#watcherunref

Docs:

When called, the active <fs.FSWatcher> object will not require the Node.js event loop to remain active

Probably something like:

process.on('SIGINT', () => {
  watcher.unref();
  watcher.close();
  console.log('Webpack closing...');
  process.exit(0);  // Exit without waiting for the watcher
});

[fregante]

Anyway, bumping watchpack to 2.4.4 fixed it 🎉