mdvorscak / metalsmith-browser-sync Goto Github PK

I tested this plugin earlier today and I would like to point out a few observations. My initial setup was metalsmith-watcher plus metalsmith-serve. My goal was to replace metalsmith-serve with metalsmith-browser-sync to benefit from BrowserSync's auto reload/inject features.

The first point where I stumbled was the files option. I assumed from the documentation that this was BrowserSync's files option. Then I was wondering why the default config watches Markdown files. I thought it should rather watch the build directory, while metalsmith-watcher would take care of the Metalsmith builds. But then I ran into endless BrowserSync reloads and then noticed two things in the source code:

1. files indicated the files that should trigger a Metalsmith rebuild upon change. It is not BrowserSync's files In the source code files is explicitly removed from the options before handing them over to BrowserSync. That's not really intuitive.
2. The next thing is the fact that under the hood this plugin uses BrowserSync to set up some watchers. This should be mentioned in the documentation. I expected this plugin to fire up BrowserSync only with no watchers.

The question is whether or not one should use Browsersync's watchers or leave the watching part to something else like Gulp or in my case metalsmith-watchers. This goes beyond this plugin, of course. The downside if this plugin's implementation is that simple BrowserSync watchers always trigger a full Metalsmith rebuild and reload, even if that's not necessary. metalsmith-watcher can do partial rebuilds.

That's why for me it feels like the watching part should be separate from the preview server part. And this would mean that metalsmith-browser-sync should just look at the build directory and reload when there is a change and another plugin should take care of the watching part and triggering (partial) rebuilds when source files change.

One of the items in my build process was failing because it had bad input. Where the non-browser-sync pipeline would have failed and output an error message, ms-browser-sync just tells me "[BS] Reloading Browsers..." without so much as a warning that something went wrong. I know there's an option available with debug to display the error, but showing the error should be the default. I shouldn't have to think "something's wrong here", quit and restart my process, and only then find out my plugin is warning me of bad input.

With this project, when running make serve and after changing something in the css, the changes are registered by browsersync:

[BS] File changed: src/css/index.css

But there's no rebuild and no refresh. When I change something to a template however, a rebuild and subsequent refresh are successfully triggered. Any idea what could be causing this? It should be rebuilding in both cases right?

Having a slow refresh with this plugin used. Looking at the build system it seems to trigger multiple builds as the build folder appears and disappears several times in file tree of Sublime Text when BS in running before it stays. Tried to move the BrowserSync after or before the build itself but it doesn’t have any effect.

I have a strange behaviour here while replacing watch and serve plugins by browsersync plugin.

I have a collection of documents which are lister on the front page.

When I run metalsmith-broswersync, each time a change is detected and the updated website a reloaded, the whole collection of documents is appended to itself and then I can find each document in double. When I modify a document one more time, the whole collection of documents is appended to itself one again, and each document is now present three times. And this goes again and again each I change a file.

Do you know if this is a desired behaviour, or a bug? Is there any workaround for this?

All in the title - this plugin works great but I'd prefer if it didn't open the browser by default on start. Any way to turn that off?

OS: Window 7

After interrupting metalsmith's node process with ctrl+c, browsersync's http server keeps running and requires manual termination.

When I try to use browserSync, I'm getting this error
This is my index.js

Any suggestions to fix it?
Cheer

$ node index.js 
/home/franklin/b0x/Projects/blog/node_modules/metalsmith-templates/node_modules/async/lib/async.js:22
            if (called) throw new Error("Callback was already called.");
                              ^
Error: Callback was already called.
    at /home/franklin/b0x/Projects/blog/node_modules/metalsmith-templates/node_modules/async/lib/async.js:22:31
    at /home/franklin/b0x/Projects/blog/node_modules/metalsmith-templates/lib/index.js:63:25
    at Function.exports.handlebars.render (/home/franklin/b0x/Projects/blog/node_modules/metalsmith-templates/node_modules/consolidate/lib/consolidate.js:499:5)
    at /home/franklin/b0x/Projects/blog/node_modules/metalsmith-templates/node_modules/consolidate/lib/consolidate.js:146:25
    at /home/franklin/b0x/Projects/blog/node_modules/metalsmith-templates/node_modules/consolidate/lib/consolidate.js:99:5
    at fs.js:336:14
    at FSReqWrap.oncomplete (fs.js:99:15)

On first run of my build.js file, everything works fine. Whenever I edit a file, .md or .jade, the browser reloads, but I get a 404 error. Has anyone else run into this issue?

build.js file:

var metalsmith = require('metalsmith'),
    layouts = require('metalsmith-layouts'),
    inPlace = require('metalsmith-in-place'),
    markdown = require('metalsmith-markdown'),
    browserSync = require('metalsmith-browser-sync'),
    moment = require('moment'),
    collections = require('metalsmith-collections'),
    beautify = require('metalsmith-beautify');

var siteBuild = metalsmith(__dirname)
    .metadata({
        site: {
            title: 'MetalSmith test'
        }
    })
    .source('./src')
    .destination('./build')
    .use(collections({
        posts: {
            pattern: 'posts/*.md',
            sortBy: 'date',
            reverse: true
        }
    }))
    .use(markdown())
    .use(layouts({
        engine: 'jade',
        moment: moment
    }))
    .use(browserSync({
        server : 'build',
        files  : ['src/**/*', 'layouts/*.jade']
    }))
    .build(function(err) {
        if(err) {
            console.log(err);
        }
        else {
            console.log('We did it!')
        }
    });

In my Metalsmith build scripts I've added support for conditional plugins. I achieve this by wrapping the existing plugin in a new conditional plugin. It looks like this in the Metalsmith build pipeline:

// Conditionally watch and serve with BrowserSync.
.use(conditionalWatchMode(browserSync(browserSyncOptions)))

And the conditional wrapper looks something like this simplified version:

function conditionalWatchMode (plugin) {
    return function (files, metalsmith, done) {
        if (isWatchEnabled) {
            plugin(files, metalsmith, done);
        } else {
            done();
        }
    };
}

However, this wrapped plugin model causes problems with this metalsmith-browser-sync plugin because the plugin depends upon the availability of a plugin name property to prevent multiple instances of browserSync from starting. When this plugin is wrapped, the wrapping plugin doesn't echo the _pluginName property and therefore the bs plugin is never removed from the chain. The end result is that everything seems to work fine, but browserSync doesn't pick up the updated content when the sources have changed (it notices that the files have changed and refreshes the browser, but still serves the old/original content).

I've thrown together an example build script and package.json in this Gist.

Here's my metalsmith pipeline:

metalsmith(__dirname)
  .use(markdown())
  .use(prism())
  .use(metadata())
  .use(permalinks())
  .use(inplace())
  .use(layouts())
  .use(assets())
  .use(sass())
  .use(prefix())
  .use(uglify())
  .use(browsersync(files: [
    "layouts/**/*",
    "pages/**/*",
    "assets/**/*"
  ]))
  .build();

Any ideas? Do I need to be running browsersync in a separate pipeline branch or something?

Also, I'm not getting any file change logs, just the reload: