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.29.0 #8

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Update dependency browser-sync to ~2.29.0 #8

wants to merge 1 commit into from

Conversation

renovate[bot]
Copy link

@renovate renovate bot commented Dec 8, 2021 •
edited

Mend Renovate

This PR contains the following updates:

Package Change Age Adoption Passing Confidence
browser-sync (source) ~2.10.0 -> ~2.29.0 age adoption passing confidence

Release Notes

BrowserSync/browser-sync (browser-sync)

v2.29.3: The one that fixes snippetOptions

Compare Source

What's Changed

Full Changelog: BrowserSync/browser-sync@v2.29.2...v2.29.3

v2.29.2

Compare Source

v2.29.1

Compare Source

What's Changed

Full Changelog: BrowserSync/browser-sync@v2.29.0...v2.29.1

v2.29.0: The one that restores IE11 support 💪

Compare Source

What's Changed

esbuild does not support down-level transpiling as far as IE11 - so when I switched to it, it accidentally broke IE11 support 😢

This is an important issue for me - many devs that support old browsers like IE11 are doing so because their projects are used in public services, or internal applications. Not every developer out there has the luxury of supporting evergreen-only browsers.

So, IE11 will work once again 🎉. Please use the issues thread to make me aware of any problem that's preventing you from using Browsersync in your day job 💪 (and be sure to thumbs-up the issues you want to see resolved)

### IE11 works, again
npm install browser-sync@latest

Full Changelog: BrowserSync/browser-sync@v2.28.3...v2.29.0

v2.28.3

Compare Source

v2.28.2

Compare Source

v2.28.1

Compare Source

v2.28.0: the one that finally removes document.write

Compare Source

What's Changed

Full Changelog: BrowserSync/browser-sync@v2.27.12...v2.28.0

v2.27.12

Compare Source

v2.27.11

Compare Source

v2.27.10

Compare Source

v2.27.9: 2.27.9

Compare Source

What's Changed

A bug prevented the help output from displaying - it was introduced when the CLI parser yargs was updated, and is now fixed :)

Full Changelog: BrowserSync/browser-sync@v2.27.8...v2.27.9

v2.27.8: 2.27.8

Compare Source

This release upgrades Socket.io (client+server) to the latest versions - solving the following issues, and silencing security warning :)

PR:

Resolved Issues:

Thanks to @​lachieh for the original PR, which helped me land this fix

v2.27.7

Compare Source

v2.27.6

Compare Source

v2.27.5

Compare Source

v2.27.4

Compare Source

v2.27.3

Compare Source

v2.27.1: added snippet: boolean option

Compare Source

This release adds a feature to address https://github.com/BrowserSync/browser-sync/issues/1882

Sometimes you don't want Browsersync to auto-inject it's connection snippet into your HTML - now you can disable it globally via either a CLI param or the new snippet option :)

browser-sync . --no-snippet

or in any Browsersync configuration

const config = {
  snippet: false,
};

the original request was related to Eleventy usage, so here's how that would look

eleventyConfig.setBrowserSyncConfig({
  snippet: false,
});

v2.26.14: upgraded dependencies

Compare Source

This is a maintenance release to address 2 security related issues (socket.io & axios)

Happy Browsersync'in :)

v2.26.13

Compare Source

v2.26.12

Compare Source

v2.26.10

Compare Source

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: 2.26.0 -> 2.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: the listen option release

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: Bug fixes

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: Bug fix

Compare Source

fix

v2.24.3: bug fixes

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: 2.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: Bug fix

Compare Source

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

v2.23.6: Bug fixes

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: - DX release

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: 2.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: https://github.com/BrowserSync/browser-sync/issues/1363

FIXED Added pointer-events: none to notification https://github.com/BrowserSync/browser-sync-client/pull/36

FIXED Page blinking on styles reload is fixed https://github.com/BrowserSync/browser-sync-client/pull/39

v2.18.10

Compare Source

v2.18.9

Compare Source

v2.18.8: 2.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 https://github.com/BrowserSync/browser-sync/issues/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 https://github.com/BrowserSync/browser-sync/issues/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: Bug fixes

Compare Source

  • 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. BrowserSync/browser-sync@069927a

  • 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 :) BrowserSync/browser-sync@348597e

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

v2.18.4

Compare Source

v2.18.3

Compare Source

v2.18.2

Compare Source

v2.18.1: Custom HTTP Module Support

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: Fixes

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*[https://github.com/BrowserSync/browser-sync/pull/1179](https://togithub.com/BrowserSync/browser-sync/pull/1179)79

    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: 2.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: Electron support

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: 2.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) -

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate. View repository job log here.

@renovate renovate bot force-pushed the renovate/browser-sync-2.x branch from 7a21def to fce440d Compare March 26, 2022 13:07
@renovate renovate bot changed the title Update dependency browser-sync to v2.27.7 Update dependency browser-sync to v2.27.9 Mar 26, 2022
@renovate renovate bot force-pushed the renovate/browser-sync-2.x branch from fce440d to f4a1ac6 Compare June 18, 2022 12:50
@renovate renovate bot changed the title Update dependency browser-sync to v2.27.9 Update dependency browser-sync to v2.27.10 Jun 18, 2022
@renovate renovate bot force-pushed the renovate/browser-sync-2.x branch from f4a1ac6 to 31cd939 Compare November 20, 2022 20:32
@renovate renovate bot changed the title Update dependency browser-sync to v2.27.10 Update dependency browser-sync to ~2.27.0 Nov 20, 2022
@renovate renovate bot force-pushed the renovate/browser-sync-2.x branch from 31cd939 to f681ba7 Compare March 16, 2023 17:38
@renovate renovate bot changed the title Update dependency browser-sync to ~2.27.0 Update dependency browser-sync to ~2.28.0 Mar 16, 2023
@renovate renovate bot force-pushed the renovate/browser-sync-2.x branch from f681ba7 to 02a04f3 Compare March 16, 2023 21:41
@renovate renovate bot changed the title Update dependency browser-sync to ~2.28.0 Update dependency browser-sync to ~2.29.0 Mar 16, 2023
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
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
0 participants