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.

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

Turning on LiveReload by Default #220

Closed
mattdesl opened this issue Nov 9, 2017 · 4 comments
Closed

Turning on LiveReload by Default #220

mattdesl opened this issue Nov 9, 2017 · 4 comments

Comments

@mattdesl
Copy link
Owner

mattdesl commented Nov 9, 2017

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
Copy link
Contributor

fibo commented Nov 19, 2017

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

@mattdesl
Copy link
Owner Author

@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
Copy link

dy commented May 16, 2018

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
Copy link
Owner Author

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

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants