Watching and rebuild files stops working after once or twice

[Fab1en]

🐛 bug report

🎛 Configuration (.babelrc, package.json, cli command)

{
  outDir: './dist',
  outFile: 'index.html',
  publicUrl: '/',
  watch: process.env.NODE_ENV !== 'production',
  cache: process.env.NODE_ENV !== 'production',
  cacheDir: '.cache',
  contentHash: false,
  minify: process.env.NODE_ENV === 'production',
  scopeHoist: false,
  target: 'browser',
  bundleNodeModules: false,
  https: true,
  logLevel: 3,
  hmr: false,
  hmrPort: 1235,
  sourceMaps: true,
  hmrHostname: '',
  detailedReport: false,
  autoInstall: true
};

🤔 Expected Behavior

When I use the watch command, I expect that the building process updates itself automatically when I modify a file.

😯 Current Behavior

This mechanism is working, but only once for each file. The first time I modify a file after having launched the watch command, it is taken into account in the rebuild, but then the next modification does not have any effect. If I modify an other file it's working but only once. There is no message displayed when it's not working.

I'm on Linux (Ubuntu 20.04) and I use gedit as code editor. If I use vim, I have the same behavior. But if I edit the file on the command line using echo, each modification is taken into account by the rebuild process :

echo "// this is a modification" >> src/myfile.js

💁 Possible Solution

This is due to this issue : when gedit is writing modifications to a file, it copies the new content to a new file and then delete the old one. So the link between the file and the watcher is lost after the first edition.

I was able to fix it by modifying the watch function in Bundler.js :

  async watch(path, asset) {
     if (!this.watcher) {
-      return;
     }
 
     path = await fs.realpath(path);
 
+    // force unwatch an already watched path so that inotify points to the new file
+    if (this.watchedAssets.has(path)) {
+      this.watcher.unwatch(path);
+    }
 
-    if (!this.watchedAssets.has(path)) {
      this.watcher.watch(path);
      this.watchedAssets.set(path, new Set());
-    }
    this.watchedAssets.get(path).add(asset);
  }

🔦 Context

💻 Code Sample

This bug can be reproduced with the demo example and the default configuration

parcel index.html

🌍 Your Environment

Software	Version(s)
Parcel	1.12.4
Node	v10.19.0
npm/Yarn	6.14.8
Operating System	Ubuntu 20.04

[yairEO]

I have also similar problems where HMR randomly stops working

[DeMoorJasper]

Does this still occur with Parcel 2?

We created a new file watcher which is a lot more performant and reliable than chokidar.

[yairEO]

Yes I only use Parcel 2 and (beta 1 because nightlies compile with a strange error with 0 google results)

Maybe it stops working when I put my computer to sleep and resume.. not sure, but it happens daily that it stops refreshing when files change (js/css or whatever)

[DeMoorJasper]

@yairEO I've never experienced this so a way to reproduce this would be very useful

[daveverwer]

Hello 👋

I was about to log this same bug when I did a search and found this thread.

I am in the process of upgrading a project from Parcel v1 to v2 and hit this bug. I chatted it through with a friend and he tried upgrading a v1 project to v2 and also reproduced it straight away. Since it seemed to be quite an obvious bug, I assumed it was a temporary issue and didn’t report it, but I tried again today and the problem remains. I have also now found this thread and realised the conditions for reproducing it might be a little more obscure than I first assumed.

The potentially good news is that the project where this is happening is an open-source project, so it's possible it could become the reproducible case you were looking for @DeMoorJasper.

If you'd like to try and reproduce it, I can consistently reproduce it on the parcel-v2 branch of this project.

The key thing is that the file watching seems to be 100% reliable when the “main” source file is saved. It’s changes to the files that are linked from the “main” files that are problematic.

Steps to reproduce are as follows:

• Clone the repo and check out the parcel-v2 branch
• Run yarn to install dependencies
• Run yarn serve
• Open Resources/Styles/main.scss in an editor
• Save main.scss and observe that the serve process re-builds. ✅
• Open Resources/Styles/base.scss in an editor, or any of the other “child” scss files.
• Save base.scss and observe that the serve process re-builds. ✅
• Save base.scss again and observe that the serve process does not re-build. ❌
• Save base.scss once more and observe that the serve process does not re-build. ❌
• Save main.scss and observe that the serve process re-builds. ✅
• Save base.scss once final time and observe that the serve process does not re-build. ❌

It may take a few successful saves of the a “child” file until it stops triggering the re-build, but it’s pretty consistently after one successful re-build on my machine. I’m running Big Sur 11.2.3 (20D91).

This also happens when opening Resources/Styles/main.js and files linked from it, but it is much more reliably reproduced with the CSS files.

[mischnic]

@daveverwer That sounds a bit like the situation that #6072 fixed. Can you try the latest nightly (parcel@nightly)?

Also, what do you mean by "save"? Do you change the file contents or really just re-save without modifying?

[daveverwer]

@daveverwer That sounds a bit like the situation that #6072 fixed. Can you try the latest nightly (parcel@nightly)?

Also, what do you mean by "save"? Do you change the file contents or really just re-save without modifying?

Just tried this and it does seem to resolve it! Thank you!

[guyfedwards]

I have this same issue with parcel@nightly on Arch linux using NeoVim. First time compiles no problem, after that doesn't trigger any builds

[mdobroggg]

I'm also having the same issue on parcel@nightly with React after upgrading from parcel v1 to v2. Its strange though because on the first load I don't get an error and if I save a JSX file I see "Console was cleared." from HMRRuntime.js:115:16 output in the console, but my changes don't get applied. If I refresh the web page, I see [parcel] 🚨 Connection to the HMR server was lost output in the console with my changes applied, but saving a file again outputs the "console was cleared" line.

Let me know what I can provide to help fix this. In the mean time, if there is a way to have the same functionality as v1 (just refreshing the page) on save? Having to manually refresh it is a huge pain.

[mdobroggg]

Another interesting thing I noticed is that when I put an error in my JS and save the overlay showing the error shows in the browser after saving. It seems like parcel is aware of my files changes but they just aren't getting applied to the DOM

[guyfedwards]

Watching is now working for me now with parcel@next on Arch with neovim 👍

[dioptre]

This is still broken for me on parcel@next (beta 3 and v2.rc0)

[drittich]

This is still broken for me on v2.0.0. I have just upgraded from v1 and noticed the issue.

[anasrar]

installing parcel@next fix this issues

[SkyLeite]

Still broken on parcel@next (v2.0.0-rc.0)

[anasrar]

Still broken on parcel@next (v2.0.0-rc.0)

the error warning still occur [parcel] 🚨 Connection to the HMR server was lost, but rebuild and reload works

Software	Version
Parcel	v2.0.0-rc.0
Node	v16.11.1
Neovim	v0.5.1
OS	EndeavourOS

[ozgrozer]

I'm also having the same issue. HMR isn't working.

[Error] WebSocket connection to 'ws://localhost:1173/' failed: There was a bad response from the server.
[Error] undefined
[Warning] [parcel] 🚨 Connection to the HMR server was lost

Software	Version(s)
Parcel	v2.0.1
Node	v12.22.0
npm/Yarn	v8.1.0/v1.22.17
Operating System	MacOS v12.0.1

---

Update

Just added --hmr-port to the start script and looks like it fixed the issue.

"scripts": {
  "start": "parcel ./App.jsx --dist-dir ./dist --public-url / --port 1171 --hmr-port 1172"
}

[khantminsithu]

Any Update on this thread?
I am facing the same issue.
Always lose connection after refresh

[ebrensi]

I'm experiencing this problem on Arch Linux with everything updated to the latest via yay.
parcel watch is doing something on file change but it is not actually rebuilding. I have to manually run parcel build to see any results of changes. What's weirder is that it is stuck on a version of the .ts file in question from last week. I have tried deleting Parcel's cache but that old file seems to be stuck there. If I do a parcel build I get the correct updated build, but if I try parcel watch, it goes back to that random old version of the file. I don't get it. If I change the name of the file then it will build once correctly, but if I change it back to the previous name I get that same old version again. It's like it is being cached somewhere.

I have another machine running Pop_OS 21.04 (Ubuntu) and it seems to work fine.

EDIT: it appears that the cache-busting filename hash is not changing so my browser is using an old cached version. If I look at Parcel's output in /dist the file is changing. It's just that the filename is not changing.

ok never mind. My issue seems to be a case of #1305
It's solvable in my case by doing a "hard-reload" in Chrome (shift-ctrl-r). Hope this helps someone.

[mrawshan]

The connection to the HMR server was lost after I unlocked the computer. And the changes will never show on the page. To prevent this, I used hot module replacement in my javascript file.

Simply add the below line of code into a javascript file.

if (module.hot) { module.hot.accept(); }

It's worked for me. I hope this will help

[Lkey-design]

I ran into this problem today. All day long I can't figure out what the problem is.

Yesterday parcel worked fine with this configuration:

{
  "name": "bricks-child",
  { "version": "1.0.0",
  { "description": "concept multidecor iluminate",
  { "targets": {
    { "front-js": {
      "source": "./decor/app/public/wp-content/themes/bricks-child/src/front/js/main.js",
      "distDir": "./decor/app/public/wp-content/themes/bricks-child/dist/front/js/"
    },
    { "front-css": {
      "source": "./decor/app/public/wp-content/themes/bricks-child/src/front/css/style.css",
      "distDir": "./decor/app/public/wp-content/themes/bricks-child/dist/front/css/"
    }
  },
  { "scripts": {
    "watch": "parcel watch --hmr-host localhost",
    }, "build": { "parcel build"
  },
  { "keywords": [],
  { "author": "",
  { "license": "ISC",
  { "devDependencies": {
    "cssnano": "^6.0.1",
    { "node-sass": "^9.0.0",
    { "parcel": "^2.9.1",
    "postcss": "^8.4.24",
    "punycode": "^1.4.1",
    "querystring-es3": "^0.2.1"
  },
  { "dependencies": {
    "gsap":"^3.11.5",
    "p5": "^1.6.0",
    "three": "^0.152.2",
    "webgl-utils.js": "^1.1.0"
  }
}

Today HRM doesn't work after 2-3 changes. The first change updates the page normally. The next ones indicate that:

Error: ENOENT: no such file or directory, unlink 'D:\Development\decor\app\public\wp-content\themes\bricks-child\dist\front\js\main.js.3020.8'

I tried different version 2.9.0, nightly, but it doesn't help.

I also completely reinstalled packages

Need any help

[swekage]

I also suddenly experienced this recently, and realized it was because I upgraded from 2.8.2 to 2.9.3.

It worked again after I reverted.

[bjornhanson]

I'm not getting any hot module reloading or page reloads when updating React components. Running Parcel v2.9.3 with React 18 on macOS 13.5.1. If I save the index.jsx file that is pulled in from the index.html file, the page reloads, but if I save App.jsx or anything down the tree, nothing happens. (The index.jsx file is where the createRoot function from react-dom/client is being called.) I see parcel HMR websocket messages coming in, but the page doesn't update.

When I save a .jsx files down the tree, I see Console was cleared in the console. I can update CSS (in a .scss file) and see that change automatically apply to the page, but I'm not seeing any React components update or cause a page reload (either would be better than nothing). I'm trying to update from Parcel 1, but ever time we've tried to update to Parcel 2, it hasn't worked. When don't want to have to manually reload the page on every change if we don't have to.

I tried downgrading to Parcel 2.8.2 and that didn't fix the problem.

[majid4466]

We have a situation that looks like the issue here.

In a legacy code base we have an intermediate step; whenever we change something in source files we need to run a script that does some preprocessing on the files and writes half baked files to a .build directory. We have Parcel watch and serve from this directory.

HTML changes are picked up correctly, but when a .scss file changes, the change does not show in the page being served with Parcel, unless we delete .parcel-cache. So, deleting .parcel-cache is our workaround for now but that sort of defeats the purpose of using Parcel.