Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update dependency browser-sync to ~2.26.9 - autoclosed #147

Closed
wants to merge 1 commit into from
Closed

Update dependency browser-sync to ~2.26.9 - autoclosed #147

wants to merge 1 commit into from

Conversation

mend-for-github-com[bot]
Copy link

This PR contains the following updates:

Package Type Update Change
browser-sync (source) devDependencies minor ~2.9.11 -> ~2.26.9

By merging this PR, the below vulnerabilities will be automatically resolved:

Severity CVSS Score CVE
High High 9.8 CVE-2020-15256
High High 9.4 CVE-2021-31597
High High 9.1 CVE-2019-10744
High High 8.6 CVE-2021-23434
High High 8.1 CVE-2020-28502
High High 8.1 WS-2020-0443
High High 7.5 CVE-2021-27292
High High 7.5 CVE-2017-16138
High High 7.5 CVE-2014-10064
High High 7.5 CVE-2020-28469
High High 7.5 CVE-2021-3805
High High 7.5 CVE-2016-10540
High High 7.5 CVE-2017-1000048
High High 7.5 CVE-2021-3749
High High 7.5 WS-2014-0005
High High 7.5 CVE-2020-36048
High High 7.5 CVE-2020-36049
High High 7.3 CVE-2020-7774
High High 7.2 CVE-2021-23358
Medium Medium 6.5 CVE-2018-3721
Medium Medium 6.1 CVE-2014-6393
Medium Medium 6.1 CVE-2013-7370
Medium Medium 6.1 CVE-2013-7371
Medium Medium 6.1 WS-2013-0004
Medium Medium 5.9 CVE-2020-28168
Medium Medium 5.4 CVE-2018-3717
Medium Medium 5.3 CVE-2017-16137
Medium Medium 5.3 CVE-2014-7191
Medium Medium 5.3 WS-2013-0003
Medium Medium 5.3 CVE-2020-7608
Medium Medium 4.3 CVE-2020-28481

Release Notes

BrowserSync/browser-sync

v2.26.9

Compare Source

v2.26.7

Compare Source

v2.26.6

Compare Source

v2.26.5

Compare Source

v2.26.4

Compare Source

v2.26.3

Compare Source

fixes

v2.26.2

Compare Source

v2.26.1

Compare Source

v2.26.0

Compare Source

these notes describe the change from 2.24.6 -> 2.26.0

fixes

chore

  • move cypress to top-level dep 0d4ab81
  • package-lock files 900e23e
  • change API of option transforms ef12e9a

lerna

feature

  • adding 'listen' option to restrict binding of interfaces d641916

docs

deps

  • npm audit for localtunnel - fixes #​1587 27f2173
  • easy-extender@2.3.4 cypress@3.1.0 supertest@3.1.0 a6578a3

v2.25.0

Compare Source

Browsersync can now be used in more restrictive areas, ones where you cannot simply bind to all addresses on the host (such as schools or universities) - this is enabled via the listen option.

For backwards compatibility reasons, we actually cannot use the host option to acheive this (even though that would make the most sense), as it would break some people's existing setups.

This is mainly because in the past, host was not used to determine an address to bind to, but rather just as a way of changing the urls Browsersync displays to the user. :( :( :(

It was a big mistake, but now with the sheer size of the user base we have, every tiny change to any existing option causes some kind of breakage. I'm not prepared to do that again with host.

So, instead we're back to the old method of instead adding a new option, that I've called listen. It's the only way we can acheive the goal without breaking existing users who are using host for other reasons.

The idea is that you'd only ever use the listen option if you want to restrict the address being bound to. For example, the following will serve files from the current directory, but behind the scenes Browsersync will only bind to localhost (this does mean that other features such as external urls will not work any more, but if you need this listen option in the first place, that will not be a concern for you)

npm i -g browser-sync@2.25.0
browser-sync . --listen localhost

v2.24.7

Compare Source

fix

deps

  • easy-extender@2.3.4 cypress@3.1.0 supertest@3.1.0 a6578a3

v2.24.6

Compare Source

v2.24.5

Compare Source

fix

v2.24.4

Compare Source

fix

v2.24.3

Compare Source

2.24.0 was a very large release - and with that, a handful of patch releases inevitably follow. Please move straight to 2.24.3 :)

fixes

v2.24.2

Compare Source

v2.24.1

Compare Source

v2.24.0

Compare Source

Features

  • (client) rewrite to Typescript + RxJS 99a69ce
  • (client) make initial options available in initial payload 9d9dfb1
  • (client) added injectNotification option & defaulted to false 06608fb
  • (client-js) allow functions in client:js hook 4803786
  • (http-protocol) support POST requests over HTTP Protocol e4754c9

Fixes

  • (client, rxjs) fix imports to avoid the entire library being bundled b8685bc
  • (cli) remove watch boolean when false b41f602

Dependencies

Tests

  • add cypress for integration tests 31bace2

misc

  • Resolved warning in tsconfig. 1c9ae43
  • Merge pull request #​1547 from jgravois/patchbump localtunnel to resolve security vuln nag 8a957e9
  • bump localtunnel to resolve security vuln nag 31956ab
  • Merge pull request #​1544 from SergiuNegara/fix/steam-docs-spellingFix stream docs spelling 78c3854
  • Fix stream docs spellingChange teh to the 4ce533c

v2.23.7

Compare Source

  • fix(client): CSS injection broken in older browsers due to use of Array.from - fixes #​1539 66dd19c

v2.23.6

Compare Source

v2.23.5

Compare Source

v2.23.4

Compare Source

v2.23.3

Compare Source

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

Compare Source

CLI

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

v2.23.1

Compare Source

2.23.1 (2018-01-01)

v2.23.0

Compare Source

  • 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.

v2.22.0

Compare Source

v2.21.0

Compare Source

v2.20.1

Compare Source

v2.20.0

Compare Source

v2.19.0

Compare Source

v2.18.13

Compare Source

v2.18.12

Compare Source

v2.18.11

Compare Source

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 BrowserSync/browser-sync@1a0505c

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

Issue: BrowserSync/browser-sync#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

v2.18.10

Compare Source

v2.18.9

Compare Source

v2.18.8

Compare Source

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.

FIXED: de2e2fa added watchEvents option to solve BrowserSync/browser-sync#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 BrowserSync/browser-sync#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);

v2.18.7

Compare Source

v2.18.6

Compare Source

v2.18.5

Compare Source

v2.18.4

Compare Source

v2.18.3

Compare Source

v2.18.2

Compare Source

v2.18.1

Compare Source

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.18.0

Compare Source

v2.17.6

Compare Source

  • 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

v2.17.5

Compare Source

v2.17.4

Compare Source

v2.17.3

Compare Source

v2.17.2

Compare Source

v2.17.1

Compare Source

v2.17.0

Compare Source

  • ADDED - better support for per-route static file serving BrowserSync/browser-sync@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** support opn's options for loading a browser with arguments BrowserSync/browser-sync#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'
]
});

v2.16.1

Compare Source

v2.16.0

Compare Source

2 fixes & a really useful new option.

  • FIXED - the version number of the Browsersync client script is now added as a query param instead of within the file path. This is a massive help for users that have the snippet saved in a file.

    Fun fact: other than a sanity check to show which release of Browsersync you're using, the version number actually serves no purpose, and that's why:

  1. it should've never been part of the the path in the first place as it caused problems for people upgrading
  2. you've always been able to access the JS file without the version number at the end, but this wasn't the default... so no one did it... so I've fixed it now instead 👍

  • ADDED - new option cors: true - setting this will ensure that all assets served by Browsersync (including the script file itself) in all modes will have HTTP access control headers added.

    This allows any domain to access your files, which can lead to some creative workflows - for example, you could create a chrome extension that added some files you have locally into a live site & have Browsersync auto-update them when they change.

enjoy :)

v2.15.0

Compare Source

Updates from 2.14 -> 2.15

  • Added: proxy.proxyReqWs to allow users to intercept/alter proxied web sockets (this is an api mirror to the underlying http-proxy lib) BrowserSync/browser-sync@277c17c
  • Fixed: protocol-relative URL rewriting now works as expected, which solves issues faced by WooCommerce users BrowserSync/browser-sync@42059df - so that now this...
<a href="//some-protocol-relative.com/some-path">My Link</a>

is correctly re-written to something like...

<a href="//localhost:3000/some-path">My Link</a>

eg:

$ browser-sync start --proxy 'localhost:8000' --https

v2.14.3

Compare Source

v2.14.2

Compare Source

v2.14.1

Compare Source

v2.14.0

Compare Source

This release includes the addition of a few new options.

  • script.domain for situations where you want full control over the domain used to serve the client JS
  • localOnly for situations where you need to opt-out of Browsersync's dynamic host rewriting.

See the previous discussion for details, but here's the tl;dr:

Browsersync goes out of it's way to 'just work' in most use-cases - but this requires some dynamic aspects that are OTT for something as simple as an Electron workflow, where you probably just want to reload files when they change.

Electron users

To have Browsersync watch over your files and reload your app when they change, just use the localOnly flag & then copy/paste the snippet into your footer.

cli

browser-sync start --localOnly --files './app'

api

const bs = require('browser-sync').create();
bs.init({
  localOnly: true,
  files: './app'
});

Adding localOnly will remove any attempts to set the domain automagically in script tags or WebSocket addresses and instead will hard-code the correct localhost address. This is exactly what is needed for use in electron.

v2.13.0

Compare Source

v2.12.12

Compare Source

v2.12.11

Compare Source

v2.12.10

Compare Source

v2.12.9

Compare Source

v2.12.8

Compare Source

v2.12.7

Compare Source

v2.12.6

Compare Source

v2.12.5

Compare Source

v2.12.4

Compare Source

v2.12.3

Compare Source

v2.12.2

Compare Source

v2.12.1

Compare Source

As work continues on Browsersync V3, I've decided to take some time to back-port some improvements that have been discovered during the re-write. Many new features are not compatible with the architecture of this 2.x master branch, but those that are have made it into this 2.12 release.

Proxy

  • Add proxyReq & proxyRes to better align with http-proxy API - this allows you to modify the request before and after it hits the target.
  • Remove foxy module, bring proxy code into core. There was too much duplication & glue-code caused by having the proxy module separate and given they are intrinsically linked, it made sense to keep all of the logic together.

Middleware

  • Allow middleware to be registered per-route. Previously, if you wanted to only apply a middleware based on a route, you had to check the url manually, now you can mix & match 'global' middleware that affect every request with more targeted ones that only act when a particular
    route is hit. (see below for examples)

CLI

  • Switch from meow to yargs - for more features re: processing CLI input
  • Allow dot notation - to enable nested properties (eg: --proxy.ws)
  • Allow multiple items per option (eg: --files "*.html" "*.css")
  • Allow per-command help (eg: browser-sync start --help, browser-sync recipe --help etc)
  • Add short-hand alias for common options (eg: -s for server, -p for proxy etc)
  • Accept config from browser-sync key in package.json #​1040
  • Allow flags to override all other forms of config

Plugins

  • Allow options in query strings - a big help when using the cli + plugins
    • (eg: browser-sync start -s --plugins bs-html-injector?files[]=*.html)

Snippet

  • Append snippet to end of document - by far the most commonly reported bug is a result of the deliberately simple regex used to insert the script tag directly after the first <body> tag. During testing for V3 I discovered that every single browser that we support is more than happy to accept a JS file that is loaded as the final thing on the page (even after the body/html tags) - this discovery alone should solve the countless hours that have been consumed reporting & replying to issues related to this.

Bug fixes

  • Always show 'codeSync' option - in sync-option in UI - #​931 #​802
  • Don't clobber existing url params on injected files - part of #​687

Examples

Below are a few examples showing what is now possible in 2.12.0

Proxy - proxyReq & proxyRes

proxy: {
    target: "http://www.bbc.co.uk",
    /**
     * Functions given here will be called with the proxy 
     * request object *before* it hits your application
     */
    proxyReq: [
        function (proxyReq) {
            proxyReq.setHeader('X-Special-Proxy-Header', 'foobar');
        }
    ],
    /**
     * Functions given here will be called with the response 
     * object *before* it hits the browser
     */
    proxyRes: [
        /**
         * Here you have access to the raw response from your
         * application *before* it hits the browser
         */
        function (res) {
            res.headers['some-other-header'] = 'value';
        }
    ]
}
Middleware - applied on a per-route basis

Before - you needed to check the url manually

middleware: [function (req, res, next) {
    if (req.url.match(/^\/api/)) {
        // some middleware logic
    } else {
        next();
    }
}]

After - define the route up front

middleware: [
    {
        route: "/api",
        handle: function (req, res, next) {
            // some middleware logic
        }
    }
]

Mix and match - some middleware are global, some per-route. No problem. Here's an example where 2 global middleware apply to every route, and one applies to /api only

middleware: [
    require("compression")(), // global gzip middleware
    function (req, res, next) {
       // some other generic middleware
       next();
    },
    {
        route: "/api", // per-route
        handle: function (req, res, next) {
            // some middleware logic
            // like handing the request off to a proxy etc
        }
    }
]
CLI improvements

new short hand examples

  • -p = --proxy
  • -s = --server
  • -f = --files
  • -b = --browser
  • -c = --config
  • --ss = --serveStatic
### Start a server from the `app` directory, watching all files
$ browser-sync start -s 'app' -f 'app'
### Proxy a PHP app + serve static files & watch them
$ browser-sync start -p 'mylocal.dev' --ss 'public' -f 'public'
### Start Browsersync from a config file
$ browser-sync start -c conf/browser-sync.js
### Start Browsersync from a config file with overriding flags
$ browser-sync start -c conf/browser-sync.js --port 4000

inline plugin options

### 1. Start a server from the `app` directory
### 2. Register the bs-html-injector plugin with files: ['*.html'] option
browser-sync start -s 'app' --plugins bs-html-injector?files[]=*.html

Have fun!

This is meant to be a non-breaking-change release, so please inform me if you encounter any issues. :)

v2.11.2

Compare Source

v2.11.1

Compare Source

v2.11.0

Compare Source

v2.10.1

Compare Source

This is an important bug-fix release related to gulp-style workflows. The stream() method accepts a 'match' option to exclude things such as .map files - this was broken for directories beginning with a . (dot) - this is now fixed in this release, so the following will work as you expect

gulp.task('styles', function () {
  return gulp.src('.tmp/scss/**')
    .pipe(sourcemaps.init())
    .pipe(sass().on('error', x => console.log(x)))
    .pipe(sourcemaps.write('./'))
    .pipe(gulp.dest('.tmp/css'))
    .pipe(browserSync.stream({match: '**/*.css'}));
});

v2.10.0

Compare Source

v2.9.12

Compare Source

  • If you want to rebase/retry this PR, click this checkbox.

@mend-for-github-com mend-for-github-com bot added the security fix Security fix generated by WhiteSource label Feb 5, 2022
@mend-for-github-com mend-for-github-com bot changed the title Update dependency browser-sync to ~2.26.9 Update dependency browser-sync to ~2.26.9 - autoclosed May 6, 2022
@mend-for-github-com mend-for-github-com bot deleted the whitesource-remediate/browser-sync-2.x branch May 6, 2022 12:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
security fix Security fix generated by WhiteSource
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

BrowserSync Notify
0 participants