Turning on LiveReload by Default

[mattdesl]

The response is positive, so I think I will turn on LiveReload by default so that you won't need to specify --live. Most of the time when using budo, you will want a LiveReload server.

So the below will be all you need to start:

# browserify a source file
budo index.js

# run a regular LiveReload-enabled HTTP server on port 8080
budo --port 8080

Since this is a major version bump, I am also going to remove (or deprecate) the live() and watch() functions in favour of passing options to budo's constructor, and adding a new function called setLiveReload in the rare case that somebody needs to change the options after connection. The reason the live() and watch() functions are currently separate, is so that you can set up a LiveReload server without a file watcher, and vice versa, but I've found the added complexity is not worth the hassle for the vast majority of users.

So it could look like this:

// Turn off LiveReload
budo.cli(process.argv.slice(2), { live: false })

// Simplified version: match filename, don't trigger JS reloads
budo.cli(process.argv.slice(2), { live: '*.{html,css}' })

// Advanced settings and configuration
budo.cli(process.argv.slice(2), {
  live: {
    // Custom options for LiveReload server and chokidar
    watchGlob: [ '**/**.{html,css,less}' ],
    ignoreWatch: [ 'some/folder/path/**' ],
    poll: true,

    // Advanced options for budo LiveReload client handling
    expose: true,
    cache: false,

    // Ability to turn on/off the LiveReload `<script>` tag injection
    injectScript: false,

    // By default, watch events trigger reload. You can set this to
    // false and then attach your own event handlers if you want to,
    // for example, selectively reload budo or do something before
    // triggering reload.
    reload: false
  }
})

This will also resolve the #219 issue.

[fibo]

I have a lot of npm scripts with --live will they break?

[mattdesl]

@fibo Nope, it would not break. Also, you should use budo as a devDependency in your npm scripts, so that if/when I push a major breaking change, your scripts will still run fine since they depended on an earlier (major) version of budo.

[dy]

I run regl tests oftentimes, which are really expensive, and enabling --live would just unnecessarily hang browser at any times any file is saved. That would also hang bad/unfinished scripts on occasional save. Practically speaking, thanked budo for not having --live enabled many times. The cost is high for long scripts, hope there is stats proving that the profit covers the need to every time enable budo with live reload disabled.

Enabling ENV settings from #218 would be really convenient and solve this problem too btw.

[mattdesl]

I do not think I am going to end up implementing this after all.

Yes, it's a bit annoying to type out --live all the time, but introducing live reload by default will cause a of lot of subtle changes, including some new API changes and breakages which I do not want to introduce. Honestly, budo is pretty stable at this point, and I'd rather not go breaking it or forcing users to change their way of working with it. :smile:

There are also some good reasons to keep it off by default, as @dy points out. Basically, budo is a browserify server by default, and optionally also a dev/LiveReload server with the --live flag.