I always run hugo server -w and I would imagine that that’s the behavior the vast majority of people desire as well.
I’m considering making --watch the default and adding another flag to not watch.
I think hugo --watch should not be the default and should continue to work like it does today.
Any feedback?
You can start by making it clear what you think …
sorry. Struggling to be clear here.
I think server should watch by default.
I think building shouldn’t watch by default.
Currently both don’t watch as the default.
Ah… I didn’t even know that --watch was a flag for the hugo command. I even see --noTimes – and would consider that a bug.
As to the question: I believe me and 99.9% of others are using hugo server -w most of the time, but this will be a potentially very breaking change for those 0.01% – so it should be put fairly high up in the release notes.
I use Hugo in a larger setting where I watch all my code with a watcher and a browser sync (npm stuff)
To me Hugo is not a kitchen sink it’s a generator. It’s a piece in a bigger workflow so having to to explicitly turn it off from being “helpful” is not great.
That said I would just have to build in the --nowatch into my script so not the end of the world, albeit in the npm world I have yet to see a package which has a built in watcher that I must tell not to fire. That’s kinda the node philosophy, do one thing well, then combine good things (modules) into something functional and customized rather than being at the mercy of the developers.
IMHO Opt in is better than opt out. It’s kinda like java forcing me to uncheck the the “ask toolbar” box every time :-).
Do you use hugo to build or build and serve in your larger workflow?
But it is a workflow in it’s own right if we want it to be. And I would say that is what the default should be focused on.
I agree very much with @spf13 's conclusion. Most users I think will want server with watch. Those of us using Hugo within other scripts will know how to override it anyway. Therefore I think the focus as far as default use should be the user who is using Hugo only.
[quote]Therefore I think the focus as far as default use should be the user who is using Hugo only.
[/quote]
+1 for setting ‘watch’ as default.
Btw, I posted the above content via email two days ago, but just discovered it never went through…
Clearly Hugo is like say Hexo being designed to be a complete environment (but for example it doesn’t deal internally with with precompling scss nor deployment).
Hugo is currently #4 on the list of generators and for good reason it’s great. If the developers (Steve) felt like they wanted Hugo to be used more universally (as a tool in other workflows) then it should accommodate that usage and that in general means supporting a robust set of CLI options including the handful of directory settings like “contentdir” that are now set in the config file.
With such it would be easy to write say a gulp wrapper for Hugo. That’s what makes libsass great for example over ruby-sass. It’s a compiled binary writtern in C, super fast with a rich set of cli options so it can be used in any workflow environment (e.g. gulp -> node-sass, gulp-sass). Hugo could be the same, it’s already compiled and fast.
So here is a thought to make everyone happy.
Allow a setting in the config file for watching that way those using Hugo as a stand alone “environment” are happy but keep the command line nowatch as a default for the larger community.
turns out my suggestion has already been done so what are we talking about here? Please just leave the default for command line alone. Those who prefer to use hugo as their “environment” can use this setting with “true”.
watch filesystem for changes and recreate as needed
watch: false
The config options are clear, and your previous workflow argument was also clear. So I’ll add my point again. As far as I’m concerned Those who prefer to use hugo as their “environment” are the users Hugo’s defaults should be focused on.
@spf13 As long as you retain the ability to set watch: false or watch = false, I see no reason as to why it shouldn’t be the default behavior. The workflow I’m building out is actually similar to @dkebler, but I would bet 90%+ of users are adding the -w/--watch from the CLI anyway. Jekyll went to a default watch as well—can’t remember when–but nobody seems to mind. I think that if you’re going to spend tens of hours on a site anyway, you’re most likely going to at least write an alias or other script to get your environment up and running (eg, I have an Applescript I use for my Jekyll site that allows me to get my grunt workflow, jekyll server, sublime text, chrome localhost, yada, yada) by pressing a total of four keys after starting up my Mac.
That said, @dkebler, I could definitely use some pointers on integrating browsersync and gulp into a Hugo workflow. Do find adding a watch with a rebuild (ie, rather than running a watch with a server) detracts from Hugo’s blistering speed? If so, I’m not sure it’ll will be worth it, since I’m ultimately moving from Jekyll to Hugo because perf is crucial.
If this thread is in the spirit of adding default functionality, @spf13, I would love if Hugo could write something like an index.json file right out of the box. Or at least write to JS/JSON in some capacity…this adds a lot of cool flexibility for adding search with something like tipue or http://lunrjs.com/, both of which hold up pretty well for sites that < few hundred pages.
We did make the change for 0.15 which was released earlier this week.
Hugo is very fast when watching without server. It’s slightly faster with the latest version when running with server because it avoids writing to the disk at all.
So we are talking about around 1ms per page when writing to disk (depends on your disk speed)… and around .7 ms per page when serving from memory. I’m not sure what Jekyll’s exact number are but they are at least 1 magnitude slower and in some cases 2 magnitudes.
index.json would be a nice feature and not hard to do. I’d love a pull request. Perhaps start with creating a ticket explaining with detail the functionality you would want.
@spf13 No doubt it’s much faster. Hugo is freakin’ awesome. I’m working on converting a fun/small project/practice Jekyll site that uses Jekyll and Tipue to Hugo right now. I can try my hand at a pull request, but I’m brand new to Go…and programming in general, really. I’ll add a ticket momentarily, but here are the basics:
range to loop through all .Site.Pages, escape the html/md (similiar to | jsonify in Liquid), and write it to a file with a .js or .json file extension. This is spitballing, but to keep everything HTML, maybe it’s as simple as a parameter in layout/searchIndex.html that allows for a different file extension to be copied to public/.inSearch: false / inSearch = false in the toml/yaml of individual file; ie, if the following is set to true…config.toml / config.yaml with createJsonIndex = true. Maybe the default behavior should be set to false in case something like this would slow down build time for larger sites. The default destination could be static/js since this dovetails with the folder structure for themes.This would then make it really easy to add weights to each property in lunr.js using a for...in loop on the client and display results by score.
.js file instead for a var tipue_search = {}...
FTR, I think keeping Hugo focused on just content/HTML and not including other build tools (SASS, uglify, etc) is a good thing, but it feels like the JSON index is just content-focused enough to merit being a feature.