Glitch live reload fails to clear Node module cache after updating glitch.json start command

Direct answer

No. Glitch does not provide a setting to clear the Node.js require cache on restart, and a full rebuild is not required to invalidate the in-memory module cache.

The Node require cache lives inside a single Node process. If Glitch actually kills the old process and spawns a new one after you edit glitch.json, the cache is gone by definition because a new process starts with an empty cache. Stale modules after an edit therefore mean the process was not truly restarted, or the on-disk dependencies were not updated before the restart, not that the cache was not cleared.

Confirmed facts

• glitch.json can define start and watch. The watch field with include/exclude regexes controls which file changes trigger install/restart. Editing glitch.json itself is watched by Glitch.
• There is no documented glitch.json option to flush Node's in-memory require cache. Cache invalidation is a process lifecycle concern, not a configuration toggle.
• A manual full restart via the Glitch terminal refresh command reruns install and restarts the container. That is the supported way to guarantee a fresh process and fresh node_modules on disk.

Likely explanation for your symptom

Live reload / file watcher may fire without a full process kill, or the new start command points to a different entry point while node_modules on disk still contains the old dependency versions. In that case the new process loads the old files from disk and the old code appears to persist. Changes to files outside the watch set, or to node_modules, will not trigger a restart by default.

Steps needed for this case

1. Confirm a real process restart happened. Log process.pid at startup and compare before and after the glitch.json edit. If the PID is unchanged, the watcher did not restart the process.
2. Ensure the changed paths are watched. Review glitch.json watch include/exclude patterns so the entry point and relevant source files trigger a restart.
3. If dependencies changed, update them on disk before restart. Run install in the Glitch console or use refresh, which reruns install and restarts the container.
4. For a guaranteed clean start, run refresh in the Glitch terminal after editing glitch.json and the start command. Verify the new entry point runs and reports the expected dependency version.

Note: Glitch announced end of project hosting in 2025. The behavior described reflects the pre-shutdown service and may no longer be testable.

One diagnostic that changes the recommendation: does the process PID change after you edit glitch.json? If yes, the cache was already cleared by the new process and the issue is on-disk dependencies or watch configuration. If no, the restart did not fire and you need to fix watch rules or use refresh.