parcel icon indicating copy to clipboard operation
parcel copied to clipboard

Watching and rebuild files stops working after once or twice

Open Fab1en opened this issue 4 years ago β€’ 20 comments

πŸ› 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

Fab1en avatar Jan 15 '21 10:01 Fab1en

I have also similar problems where HMR randomly stops working

yairEO avatar Feb 04 '21 21:02 yairEO

Does this still occur with Parcel 2?

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

DeMoorJasper avatar Feb 07 '21 16:02 DeMoorJasper

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)

yairEO avatar Feb 07 '21 21:02 yairEO

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

DeMoorJasper avatar Feb 08 '21 08:02 DeMoorJasper

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.

daveverwer avatar Apr 05 '21 16:04 daveverwer

@daveverwer That sounds a bit like the situation that https://github.com/parcel-bundler/parcel/pull/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?

mischnic avatar Apr 05 '21 16:04 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?

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

daveverwer avatar Apr 05 '21 16:04 daveverwer

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

guyfedwards avatar Apr 13 '21 13:04 guyfedwards

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 avatar Apr 15 '21 15:04 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

mdobroggg avatar Apr 15 '21 16:04 mdobroggg

Watching is now working for me now with parcel@next on Arch with neovim :+1:

guyfedwards avatar May 21 '21 08:05 guyfedwards

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

dioptre avatar Aug 04 '21 00:08 dioptre

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

drittich avatar Oct 21 '21 13:10 drittich

installing parcel@next fix this issues

anasrar avatar Nov 05 '21 06:11 anasrar

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

SkyLeite avatar Nov 05 '21 23:11 SkyLeite

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

anasrar avatar Nov 07 '21 02:11 anasrar

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"
}

ozgrozer avatar Nov 10 '21 21:11 ozgrozer

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

khantminsithu avatar Feb 14 '22 17:02 khantminsithu

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 https://github.com/parcel-bundler/parcel/issues/1305 It's solvable in my case by doing a "hard-reload" in Chrome (shift-ctrl-r). Hope this helps someone.

ebrensi avatar Feb 28 '22 21:02 ebrensi

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

mrawshan avatar Sep 12 '22 09:09 mrawshan

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

Lkey-design avatar Jun 07 '23 09:06 Lkey-design

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.

swekage avatar Jul 10 '23 04:07 swekage

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.

bjornhanson avatar Sep 01 '23 21:09 bjornhanson

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.

majid4466 avatar Nov 11 '23 11:11 majid4466