v2.23.3

misc

• Revert "Fix the missing type: array in server field of startOpts" - fixes #1483 (This reverts commit b24514b) 31150d6
• fix(server-middleware): allow res.end -> next() in middeware flow when no serveStatic exists - fixes #1481 620e9ae

v2.23.2

CLI

• Fix the missing type: array in server field of startOpts b24514b

v2.23.0 - DX release

• Fixed: removed weinre from the UI - it was using deprecated packages, and is un-maintained. e6be4e9
• Fixed: Updated socket.io to the latest version (security advisory)
• Fixed: Allow notify command over HTTP protocol ac86665 (closes #1467)
• New: CI: build on node 8 (latest lts) 3b7e8cb
• New: Easier CLI commands for common flows. (see below) 91b7e89
• New: watch option - (see below)
• New: Supports CSS @imports - thanks to Live Reload fb26e82 (closes #10)
• New: Fall back to a directory listing if a request gives a 404 b5cc56e
• New: single option - adds a middleware to help with SPAs (serves index.html for all non-matching routes) 91480aa
• New: ignore option - shortcut for adding to watchOptions.ignored - added because of the new watch option
• Improved: Perf: Always group file-changes into flexible 500ms buffers - this will help things such as git checkout without any configuration fd3d074
• Improved: Perf: Adding adding cwd + ignore defaults to all watcher options dbb1267
• Changed: Log CSS file injections into the console (rather than the overlay, which always gets in the way) cb5b44c

Highlights

Easier CLI commands

In an attempt to streamline the common use-cases, Browsersync will now attempt to 'do the right thing' when no command is provided, for example:

To run a static server, serving from the current directory

# before
browser-sync start --server

# after
browser-sync .

To run a static server, serving from 2 directories:

# before
browser-sync start --server app/src app/tmp

# after
browser-sync app/src app/tmp

If the directory contains a 'index.html' file, you can omit any input and just run:

# after
browser-sync

You can run the proxy in this manner too

# after
browser-sync https://example.com

To run a proxy, whilst also serving static files

# after
browser-sync https://example.com htdocs/themes/example

New watch option

Because we now have the shorthand ways of launching servers/proxies, eg: browser-sync . - it also made sense to automatically watch files too. So, if watch: true - then Browsersync will make a best-guess at which files to automatically watch.

Here's a comparison to the old way (which will still work, of course)

# before
browser-sync start --server ./app --files ./app

# after
browser-sync ./app -w

Behind the scenes, Browsersync is just looking at served directories (in this case, app) and
adding it to the regular files option as normal.

It means the following the 2 configurations are identical, but the latter is better since there's no
repetition.

{
  "server": {"baseDir": ["app"]},
  "files": ["app"]
}

{
  "server": {"baseDir": ["app"]},
  "watch": "true"
}

New ignore option

Added as a convenience since we have simpler watching via the watch flag. Use it to ignore any patterns that should not cause Browsersync reloads/injections

Example:
- Serve files from the 'app' directory
- Watch all files
- But, exclude **/*.js (if using Webpack, etc)

CLI:

browser-sync app -w --ignore '**/*.js'

Config:

{
    "server": "app",
    "watch": true,
    "ignore": "**/*.js"
}

New single option, easy SPA development

This option will add the connect-history-api-fallback middleware automatically for you, meaning that developing with client-side routers can be done without configuring this middleware manually

Example:
- Serve files from the app directory
- Watch all files
- Serve index.html for all none matching routes

browser-sync app -w --single

Fall back to a directory listing if a request gives a 404

No more Cannot Get /' messages. If you run Browsersync in a directory where there's no index.html, a directory listing will be shown instead.

2.18.11

FIXED Source map files are now ignored by default. c990ea2 BrowserSync/browser-sync-client@24de0ec

Previously, if you were watching a directory into which source maps were being written (alongside your CSS/JS etc) then Browsersync would instruct all browsers to actually RELOAD as it wouldn't know how to handle the 'map' files.

This was particularly frustrating for gulp users - take this following example (where we compile sass-> css)

gulp.task('styles', function() {
  return gulp.src('app/core.scss')
      .pipe(sourcemaps.init())
      .pipe(sass())
      .pipe(sourcemaps.write('.'))
      .pipe(gulp.dest('dist'))
      .pipe(browserSync.stream())
});

With this, each time a file is saved, there would be 2 output files core.css & core.css.map and Browsersync would be informed of both. With the CSS file, it would update any references to that file in all connected browsers, but for the map file, it would perform a full page reload instead... This is never what a user expects, so I've fixed it.

---

FIXED default ghostMode.location: true 1a0505c

A recent change stopped a module being loaded on the client-side that handled UI events such as 'SYNC ALL' etc.

Issue: #1363

---

FIXED Added pointer-events: none to notification BrowserSync/browser-sync-client#36

---

FIXED Page blinking on styles reload is fixed BrowserSync/browser-sync-client#39

2.18.8

FIXED: re-implemented reloadDebounce to better suit the Browsersync use-case. Now we debounce and buffer events to allow multiple files to be injected following the specified window of event silence.

• #1192
• #203

---

FIXED: de2e2fa added watchEvents option to solve #1291 - now you can override which file-watching events Browsersync will respond to.

For example, if you wanted to respond to the add event, along with the default change event, you could provide the following

   browser-sync start --server --files "app/src" --watchEvents change add

or

const bs = require('browser-sync').create();

bs.init({
    server: 'app',
    files: ['app/src'],
    watchEvents: ['add', 'change']
});

---

FIXED: c6d7d16 always send override: true on public notify method to fix #538

This means you can now silence the default notify messages, whilst still using your own.

const bs = require('browser-sync').create();

bs.init({
    server: 'app',
    notify: false
});

setInterval(function() {
    bs.notify('5 seconds have passed!')
}, 5000);

Bug fixes

• FIXED - white-screen in UI

  Removed cache headers from run-time generated JS file that was causing a 'white screen' in the UI when switching between protocols. 069927a

  • Issue #1152
  • UI fix BrowserSync/UI@b09c594

• FIXED - accept port option as a string

  There was a regression from a dependency. I've now pinned the version to the latest that works :) 348597e

  • Issue #1254

• FIXED - don't register event handlers when ghostMode disabled

  Previously Browsersync would always register things such as click/scroll on every page load, but if you had set ghostMode: false we just wouldn't attempt to replicate those actions across devices.

  This was intentional as it allows the user to re-enable these options within the UI without requiring a full page reload, but on reflection that is very much 'unexpected' behaviour, so following this release no listeners will be registered if you explicitly opt-out of them via your configuration.

Custom HTTP Module Support

This release brings a small but important change, the ability to provide a different HTTP module to be used in place of the default ones that ship with node. This is only really interesting when you realise this effectively enables anyone to try out things such HTTP2.

We may well switch to an HTTP2 as standard in the near future (if I can figure out how to get the proxy working with it) - but for now this small change allows you to drop any old module into the place of the defaults.

API example with http2 (note that you need to install the module along with Browsersync, for now)

// First, install both browser-sync & http2 locally
//    npm i browser-sync http2
// or
//    yarn add browser-sync http2

const bs = require("browser-sync").create();

bs.init({
    files: ["app/css/*.css"],
    server: "./app",
    https: true,
    httpModule: "http2"
});

CLI example (as above)

# note: this needs to be run in a directory that has the http2 module installed
browser-sync start --server 'app' --httpModule 'http2' --https

Browsersync Proxy + custom httpModule ?

Nope, not just yet I'm afraid - if someone out there can make http-proxy play nicely with something like http2 - then please share the knowledge :)

Thanks

to @itslenny for kick-starting it :)

v2.17.6

• FIXED - stop localtunnel errors from crashing the process 80120dc

• FIXED - allow the reload command to work with https urls 3bb5b8d

  eg: If you have a Browsersync instance running at https://localhost:3000, you can instruct all browsers to reload by executing the command browser-sync reload --url https://localhost:3000. This previously failed since Browersync uses self-signed SSL certs.

• UPDATED bumped bs-recipes to include a new minimalist preact starter with hot-reloading.

  To try it out, just run the following command and follow the instructions :)

  browser-sync recipe webpack.preact-hot-loader

Fixes

• FIXED update socket.io client to fix IE9 issues #1198
• FIXED maintain order of internal options/middlewares to stop plugins from clobbering defaults #1223

v2.17.0

• FIXED https option is no longer clobbered when running from the CLI 27a08c2

---

• ADDED - better support for per-route static file serving 97dd907
  For example, let's say you have a deployed Wordpress website at http://example.com where the assets live inside wp-content/themes/awesome/. Now lets imagine you need to make small CSS tweaks in style.css, but you don't want the hassle of running PHP + MySQL on your local machine... With Browsersync you can now easily map remote paths to local ones. So if you have the file wp-content/themes/awesome/style.css on your machine, you could run the following and have your changes update the live website.

  /**
  * This example will proxy an EXISTING website
  * whilst serving assets from your local directory.
  * This is crazy-powerful, especially when you consider
  * it works across all devices.
  */
  const bs = require('browser-sync').create();
  
  bs.init({
      proxy: 'http://example.com',
      files: ['htdocs/wp-content/themes/awesome'], // watch files
      serveStatic: [
          {
              route: '/wp-content/themes/awesome',     // remote path
              dir: 'htdocs/wp-content/themes/awesome'  // local path
          }
      ]
  });

  This kind of magic was always possible with Browsersync, but it required more complicated setup that we're happy to see the back of. The best bit is that the proxy will kick in if a file is not found locally. So in our Wordpress example, you could have nothing but a CSS file and everything would still work.

  A knock-on effect of this feature is that now you can map multiple remote paths to multiple local directories... I know, it's magical and amazing.

  // map 2 remote paths to 1 local directory
  serveStatic: [
      {
          route: ['/wp-content/themes/theme1', '/wp-content/themes/theme2'],
          dir: './my-local'  // local path
      }
  ]

  // map 1 remote path to 2 local directories
  serveStatic: [
      {
          route: '/wp-content/themes/theme1',
          dir: ['./my-local', './tmp']  // local path
      }
  ]

  ---

• ADDED support for opening browsers with flags** #1179

  For example, if you wanted to open Chrome with certain flags when Browsersync starts, you can do

  const bs = require('browser-sync').create();
  
  bs.init({
  server: './app',
  browser: [
      {
          app: [
              'chromium-browser',
              '--app=http://localhost:8080',
              '--proxy-server=localhost:8080',
              '--user-data-dir=.tmp/chomium'
          ]
      }
  ]
  });

  This can also be combined with the string-only versions too - so to open chrome with flags, but safari + firefox as normal:

  const bs = require('browser-sync').create();
  
  bs.init({
  server: './app',
  browser: [
      {
          app: [
              'chromium-browser',
              '--app=http://localhost:8080',
              '--proxy-server=localhost:8080',
              '--user-data-dir=.tmp/chomium'
          ]
      },
      'safari',
      'firefox'
  ]
  });