sintaxi / harp

Static Web Server/Generator/Bundler
http://harpjs.com
5k stars 343 forks source link

LiveReload Support #80

Closed kebot closed 6 years ago

kebot commented 11 years ago

Grunt-Watch support this: https://github.com/mklabs/tiny-lr

kevinsimper commented 11 years ago

+1 For this feature

CharliePops commented 11 years ago

This would be awesome! +1

johnpeele commented 11 years ago

+1

kennethormandy commented 11 years ago

[Harp] + npmjs.org/package/instant + bit of glue = Me happy —Carsten Wölk, source

I replied to this tweet, trying to get more information on this, but never heard back. Looks like that npm module might be somewhere to start, anyway?

Also, just to clarify, the real feature request is to support automatic browser refreshing, right? Hypothetically, it wouldn’t matter if it wasn’t actually LiveReload?

silentrob commented 11 years ago

I have audited npmjs.org/package/instant and it looks perfect.

bjfish commented 11 years ago

+1

edrex commented 11 years ago

Can somebody post steps to get Harp using instant for LiveReload, to move this issue forward? @cwoelk?

edrex commented 11 years ago

Should this be a flag to the server subcommand, eg harp server -w?

kennethormandy commented 11 years ago

Personally, that’s what I was thinking, @edrex. It seems like something that should exist at the server level, not the app level. Just wondering, what does the -w stand for, though?

Then, the next question would be if it’s opt-in or out. I’d prefer if Harp auto-reloads in development unless you opt-out, but maybe that’s too much as a default, I’m not sure.

edrex commented 11 years ago

I was thinking -w for "watch" but I guess watching is different from live reload. +1 for opt out in development, since it seems like most people will want it.

edrex commented 11 years ago

This seems related to #79. I haven't dug into Harp internals yet, but I understand that in server mode documents are processed on each request. Since the instant middleware expects a static dir to watch, I don't see how it can work. #79 adds a partial dependencies registry for cached documents. It seems like this same information would be needed to know when to trigger a LiveReload. Unless a reload was triggered on any change. Thoughts @kennethormandy @sintaxi?

edrex commented 11 years ago

Harp supports two modes: server (lazy, uncached) and compile (eager, one pass). For LiveReload, a third mode is needed: compile -w. Jekyll supports this mode, but doesn't efficiently recompile. Ideally, Harp would support compile -w and serve -w efficiently, which would require tracking document dependencies in order to trigger selective document rebuilds.

I think all the feature requests currently being proposed for Harp are in danger of making it just another kitchen sink tool, so it would be interesting to see some sort of planning document/roadmap to act as a focus. Maybe live reload isn't on that roadmap?

edrex commented 11 years ago

Sorry for all the noise on this issue.

I think once #79 is merged, it should be possible to use the new cache invalidation code to also trigger a page reload.

sintaxi commented 11 years ago

Thanks for keeping an eye on this and for expressing interest in this feature. I'll take a look at how it might best be integrated into harp.

ncammarata commented 10 years ago

+1

giodamelio commented 10 years ago

:thumbsup: This would be super useful.

rooc commented 10 years ago

+1

kjunine commented 10 years ago

+1

og2t commented 10 years ago

+1 :)

Watch and reload would be very useful. I use Harp for rapid prototyping, almost like local codepen.

kennethormandy commented 10 years ago

I know one library was already evaluated and looked pretty promising, but BroewserSync looks worth checking out: https://github.com/shakyShane/browser-sync

It supports live file refreshing and CSS injection (for editing CSS during states). You can also have it sync scrolling and clicks.

rudylattae commented 10 years ago

+1

kebot commented 10 years ago

@kennethormandy that's a great solution

og2t commented 10 years ago

What would be the workflow to use it with Harp? The compiled files are only saved with harp compile but BrowserSync needs to serve them as static. So we still need compile -w right?

kennethormandy commented 10 years ago

When you run harp server, files are still getting compiled in memory, on demand. I think the browser refreshing could still take place then, without the need for an explicit watch mode—but then again, I am definitely not the person who knows the most about that.

ianrose commented 10 years ago

+1

philholden commented 10 years ago

Have you seen (Broccoli)[http://www.solitr.com/blog/2014/02/broccoli-first-release/]? It aims to be a replacement for grunt watch. However it runs on the client rather than the server.

Greyvy commented 10 years ago

+1

neverfox commented 10 years ago

I was actually surprised to find this wasn't part of Harp, and it's a bit of a dealbreaker for me. I don't think I know of another build tool without a watch/reload option.

calazans10 commented 10 years ago

ping

designnotdrum commented 10 years ago

+1 - this would make my life a billion times easier (i measured)

andrewboni commented 10 years ago

This would be awesome. +1

jamiecollinson commented 10 years ago

+1 - agree with @neverfox, I was surprised this wasn't already part if Harp. I like how roots.cx integrates livereload functionality, but I'm not quite clear how they're doing it:

https://github.com/jenius/roots/search?q=livereload

stoikerty commented 10 years ago

Love this idea, I hope it comes out soon +1

irony commented 10 years ago

+1

hnqso commented 10 years ago

+1 for this request. I can be wrong but LiveReload today isn't really a feature and it should be included as default of any static web site generator.

jwebcat commented 10 years ago

Have to say when a simple way to use either livereload or browserSync would be awesome. Pretty clutch if you ask me.

jwebcat commented 10 years ago

+1 for integration with browserSync

mrmurphy commented 10 years ago

Are there particular difficulties that keep this from being straightforward? I'm happy to take a shot at implementing it, but it seems that if it were straightforward this would've been done before. Do you have any warnings before I dive in?

kennethormandy commented 10 years ago

@murphyrandle That’d be amazing. I don’t @sintaxi or I have any reservations, and any suggestions we have are in this thread. (https://github.com/sintaxi/harp/issues/80#issuecomment-34223039, https://github.com/sintaxi/harp/issues/80#issuecomment-27515889, etc.). As long as it doesn’t break tests, anything that moves this in the right direction is greatly appreciated.

jwebcat commented 10 years ago

I can only say that I think if you are going to take the time to do this, you might as well integrate browser-sync instead of livereload, It is more robust and far better in my opinion.

On Thu, Jul 17, 2014 at 5:49 PM, Kenneth Ormandy notifications@github.com wrote:

@murphyrandle https://github.com/murphyrandle That’d be amazing. I don’t @sintaxi https://github.com/sintaxi or I have any reservations, and any suggestions we have are in this thread. (#80 (comment) https://github.com/sintaxi/harp/issues/80#issuecomment-34223039, #80 (comment) https://github.com/sintaxi/harp/issues/80#issuecomment-27515889, etc.). As long as it doesn’t break tests, anything that moves this in the right direction is greatly appreciated.

— Reply to this email directly or view it on GitHub https://github.com/sintaxi/harp/issues/80#issuecomment-49384413.

mrmurphy commented 10 years ago

Okay, I've been poking around. I don't know that I'll have time to implement it, but here's the general concept of how I think it could be done:

1) Require browser-sync as a package and create an instance that can be notified of file changes. 2) Add a middleware before the static file server that injects the browser-sync tags if the resource being requested is an HTML file. 3) Use a library like Gaze to watch all source files in the public directory. 4) Upon notification of a source file change, call on terraform to use the asset pipeline and compile that file. 5) Transform the compiled file / files into a stream. 6) Call browserSync.reload with the stream of changed files. This will either reload the page, or inject the changes appropriately.

@kennethormandy or @sintaxi does that appear incorrect?

sintaxi commented 10 years ago

@murphyrandle I think you got it right. We will also want to expose this feature with a -w flag or something like that.

mrmurphy commented 10 years ago

Sorry everyone, I ran out of time and ended up just using gulp to do a custom build instead of using Harp. I won't be implementing Live Reload.

jkarttunen commented 10 years ago

Anywhere where i can use a harp fork / branch to get this feature.?

itzaks commented 10 years ago

Here's a simple boilerplate with browsersync and browserify: harp-browser-sync-browserify. Check package.json and bs-config.js to see how it works

Globegitter commented 10 years ago

Would be great to get livereload support

kevinsimper commented 10 years ago

I implemented browser-sync, you can try it out here #360

Prinzhorn commented 10 years ago

I love the simplicity of harp and was also interested in this feature. But after a minute of research I wonder if we actually need this in harp? This works perfectly well after you've started harp:

browser-sync start --proxy 'localhost:9000' --files '*.jade, *.scss'

Following the unix philosophy I personally like to keep harp and browser-sync separated. This gives you full control over browser-sync without doing too much magic inside of harp.

tuan-ph commented 9 years ago

@Prinzhorn I do allow your step, when I enter, it's auto open browser. Unfortunately when I try to edit file, cmd screen show that file jade change, but the browser don't reload. Any ideas? Thanks!

chrisdavies commented 9 years ago

I don't think Harp needs to worry about this. This problem has been solved generically via the livereloadx tool:

http://nitoyon.github.io/livereloadx/

I just installed the Chrome extension and ran that on my harp directory, and everything is nice and fast.

Given the existence and utility of livereloadx, I agree with the Harp team on de-prioritizing this feature.