Closed kebot closed 6 years ago
+1 For this feature
This would be awesome! +1
+1
[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?
I have audited npmjs.org/package/instant and it looks perfect.
+1
Can somebody post steps to get Harp using instant for LiveReload, to move this issue forward? @cwoelk?
Should this be a flag to the server subcommand, eg harp server -w
?
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.
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.
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?
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?
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.
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.
+1
:thumbsup: This would be super useful.
+1
+1
+1 :)
Watch and reload would be very useful. I use Harp for rapid prototyping, almost like local codepen.
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.
+1
@kennethormandy that's a great solution
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?
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.
+1
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.
+1
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.
ping
+1 - this would make my life a billion times easier (i measured)
This would be awesome. +1
+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:
Love this idea, I hope it comes out soon +1
+1
+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.
Have to say when a simple way to use either livereload or browserSync would be awesome. Pretty clutch if you ask me.
+1 for integration with browserSync
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?
@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.
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.
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?
@murphyrandle I think you got it right. We will also want to expose this feature with a -w
flag or something like that.
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.
Anywhere where i can use a harp fork / branch to get this feature.?
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
Would be great to get livereload support
I implemented browser-sync, you can try it out here #360
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.
@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!
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.
Grunt-Watch support this: https://github.com/mklabs/tiny-lr