Browsersync/Gulp watch choking on many files about jigsaw

[damiani]

@cjf I haven't been able to reproduce that problem when using reloadDebounce, but granted, I haven't tested it with a site as large as yours. FWIW, I'm running Jigsaw on Valet and not using Browsersync's server, so the build process in general is super fast, and a slight debounce is enough to trim the flurry of browser reloads down to just one. My BS settings are:

.browserSync({
    port: port,
    proxy: 'http://my-demo-site.dev'
    files: [ 'build_' + env + '/**/*' ],
    reloadDebounce: 500,
    reloadOnRestart: true,
});

You could try adding the reloadOnRestart: true option to see if it prevents the dropped connections you're experiencing.

@erickpatrick You are right that Jigsaw rebuilds the entire contents of the build_* directory each time jigsaw build is run; only regenerating new or changed files, though, would require a very fundamental change to the process by which Jigsaw parses and builds a site. Finding a way to make Browsersync behave more reliably when working with a large site or a slow build would be a better approach.

[damiani]

I haven't looked into Elixir closely to see why this would be happening, but an easy fix might be to use Browsersync's reloadDebounce option—which waits for a specified period of inactivity before reloading the browser. In order to use this, though, you need to first update laravel-elixir, because the version of Elixir currently used by Jigsaw in v0.6.4 doesn't fully support reloadDebounce.

So, in your package.json, remove the laravel-elixir line, and replace it with:

    "laravel-elixir": "^6.0.0-15",
    "laravel-elixir-browsersync-official": "^1.0.0"

then run npm install from your project root.

Then, in gulpfile.js, add this option to the .browserSync({...}) step:

reloadDebounce: 2000

That will pause for 2 seconds before trying to reload, giving a long build process some time to settle down, so Browsersync doesn't freak out with all the file changes. You can adjust the debounce value as needed.

Try it out, and let me know if it fixes the issue.

[cjf]

Just tried it out. While it does keep BS from freaking out, it also seems to break it. That is, the browser connection gets dropped, so no reloading happens at all. I've tried various values for reloadDebounce (from 1 to 10000): they all have the same effect.

I did a bit of googling around to see if anyone else has the issue of the connection dropping, but I can't find anything of use.

For what it's worth, if I reload localhost:3001 to see the connections after a BS event, the connection that existed before, disappears. I can reload the :3000 window, and it reconnects, but it loses it when another BS event occurs.

[cjf]

Also, the BS code snippet is injected in the page source. I can see it.

[erickpatrick]

The problem is that the exec command on the gulpfile.js will be called every time there's a change on any build folder. As the jigsaw command (re)generate all the files, there will be a change to browsersync for each and every one of them, thus leading to various refreshes.

Ideally, jigsaw command should be smart enough to just (re)generate new or changed files, which would increase its speed and reduce the number of refreshes, potentially, to one (more than one user changing different files would still trigger more than one change event thus more than one page refresh).

[IllyaMoskvin]

Unfortunately, I have to echo @cjf. It seems that BrowserSync is being called on every file change. Adding reloadDebounce and reloadOnRestart broke the sync for me: the browser page wouldn't refresh when the site was rebuilt. I don't mind dealing with the occasional Cannot GET /, but I'm sure we can get it to sync more consistently...

I wonder if it might make sense to just watch one file for changes. I typically use LiveReload instead of BrowserSync, but if the latter acts the same, then the page will be refreshed if any watched files are updated (even if the contents don't change). I figure, if Jigsaw replaces the whole build_* folder on build, then each build is guaranteed to update that-one-file and trigger BrowserSync.

I'll give it a shot and report in re: stability.

Here's my setup for reference:

.browserSync({
      port: port,
      server: { baseDir: 'build_' + env },
      proxy: null,
      files: [ 'build_' + env + '/index.html' ],    // that-one-file

      // https://github.com/BrowserSync/browser-sync/issues/344
      notify: false,
      open: false,

      // https://github.com/tightenco/jigsaw/issues/86
      // reloadDebounce: 500,
      // reloadOnRestart: true,
});

[damiani]

We're moving toward using Laravel Mix and Webpack as the default build tooling, which seems to have much better luck running BrowserSync. See #188, which will be in the next tagged release.