Parcel: Only first change is tracked when index.html is not in the root dir

Created on 17 Jul 2018 · 18Comments · Source: parcel-bundler/parcel

🐛 bug report

When running parcel and then changing source files a few times, the page is reloaded after the first edit only and no more reloads happen.

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

parcel src/index.html

{
  "name": "parcel-example1",
  "version": "1.0.0",
  "description": "example",
  "scripts": {
    "start": "parcel src/index.html"
  }
}

🤔 Expected Behavior

Page reloads after each change.

😯 Current Behavior

Page reloads after first change only.

💁 Possible Solution

💻 Code Sample

src
  - index.html
  - main.js
package.json

<html>
  <head>
    <title>Parcel Example</title>
    <meta charset="UTF-8"/>
  </head>
  <body>
    <div id="calendar">Hello world!</div>
    <script src="main.js"></script>
  </body>
</html>

🌍 Your Environment

| Software | Version(s) |
| ---------------- | ---------- |
| Parcel | 1.9.7
| Node | 8.11.3
| npm | 6.2.0
| Operating System | Windows 10

Bug Confirmed Bug Watcher

Source

valnaumov

👍3

Most helpful comment

FYI, we've decided to build our own watcher for Parcel 2, and it should be much more reliable with safe write and other issues we've seen with chokidar. https://github.com/parcel-bundler/watcher

devongovett on 8 Apr 2019

👍2

All 18 comments

Same problem here (Windows 10). Down to Parcel 1.9.2 and works OK.

ManzDev on 17 Jul 2018

Probably a windows issue, can you create a minimal repro so someone can confirm this is windows related

_{Sent with GitHawk}

DeMoorJasper on 17 Jul 2018

Here a repo: https://github.com/ManzDev/css-grid-cards

git clone and parcel serve src/index.pug and fail on checkout branches. Test on Windows 10 Pro N and Windows 10.

Fails on Parcel 1.9.6
Fails on Parcel 1.9.7
Down to Parcel 1.9.2 and works.

ManzDev on 17 Jul 2018

👍2

Works fine on OS X

DeMoorJasper on 17 Jul 2018

I have the same problem on Ubuntu

| Software | Version |
| ------------- |:-------------:|
| Ubuntu | 16.04. |
| Node | 10.8.0. |
| Parcel | 1.9.7 |
| WebStorm | 2018.2.1 |

Trying next conditions:

parcel installed globaly
parcel installed localy
index.html in root dir
index.html in not root dir

But the result the same: parcel rebuilds only once for every file

Fixed by decreasing the version to 1.9.2 (as mentioned here)
And running sudo sysctl fs.inotify.max_user_watches=99999 to fix issue with "no space left on device" (as mentioned here)

Update 22/08/2018

Could by fixed by changing the IDE saving configuration as mentioned here

MNITD on 14 Aug 2018

Can any of the non-os x users in this thread have a look at this issue and possibly fix it.

This line might be of some interest https://github.com/parcel-bundler/parcel/blob/master/src/Watcher.js#L14

The thing is we wanted to prevent sudo sysctl fs.inotify.max_user_watches=99999, therefore we no longer watched dirs, but if this is causing issues we might want to figure out some other solution for non-mac users, or get a better cross-platform filewatcher

DeMoorJasper on 14 Aug 2018

Im having a similar issue, where parcel is running inside a docker container (debian based, node v9, entrypoint = src/index.html) and only the first change to a file is registered by parcel. Any subsequent changes to a file can be seen in the docker container but the parcel file watcher seems to not care.

How come parcel needs its own home rolled file watcher? Please consider using a more battle tested solution.

We are stuck using parcel 1.9.2 at the moment.

oskbor on 16 Oct 2018

👍1

I've tracked down the issue a bit further. Removing docker-sync from the mix actually gets file change detection working again. Somehow the parcel file watcher is not detecting all changes propagating from docker-sync.

oskbor on 17 Oct 2018

Fadora 28 parcel 1.10.3 - same problem reload works only first time for each file.

elennaro on 25 Oct 2018

😕1 👍1

I'm sure it'll break something else, but I've been able to trigger builds on multiple edits of the same time inside a docker container setting the env variable CHOKIDAR_USEPOLLING=yes. I'm not familiar with chokidar and maybe enabling the polling is a bad idea (was this causing the fs.inotify.max_user_watches issues?) , but if it does not harm it's an easy thing to enable from Parcel watcher options.

I'll try to explore a bit further on this issue because it's really annoying. It basically prevents us to upgrade from 1.9.4.

meis on 23 Nov 2018

It seems I have almost exactly the same problem here, only the two or three first changes are detected if I modify my JS file, after that Parcel does not reload the page anymore.

I checked many issues related to this :

Adding this snippet (given by @DeMoorJasper) to my entry point works but I don't see why we should implement this manually :

if ( module.hot ) {
  module.hot.accept(function () {
    window.location.reload();
  });
}

And as VSCode does not seem to use atomic saves the problem is not related to safe-write.

ko-dever on 27 Nov 2018

Ive looked a bit at other file system watchers and I think https://github.com/Axosoft/nsfw seems to be a good match to what parcel needs. Its used by VS Code among others, so it should be battle tested.

Edit: would a pull request for using __nsfw__ be welcomed?

oskbor on 27 Nov 2018

👍1

@oskbor PRs are always welcome.
If the installation is as simple as the current watcher and it’s more reliable it’ll definitely be worth it.
We’ve been trying out different watchers since the start of parcel, so we’re def very open to changing our current watcher.

_{Sent with GitHawk}

DeMoorJasper on 28 Nov 2018

Before switching too fast to nsfw you might want to see https://github.com/Axosoft/nsfw/issues/55

millette on 21 Dec 2018

Windows 10 parcel 1.11.0 - same problem :\

alzuma on 22 Dec 2018

FYI, we've decided to build our own watcher for Parcel 2, and it should be much more reliable with safe write and other issues we've seen with chokidar. https://github.com/parcel-bundler/watcher

devongovett on 8 Apr 2019

👍2

better then webpack to use

bigidea-kz on 15 Jun 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 30 days if no further activity occurs. Thank you for your contributions.