Skip to content

config.yml not reloaded when running jekyll serve --watch #2302

Closed
aldoforce opened this Issue May 6, 2014 · 28 comments
@aldoforce

Running 1.5.1, OSX.

To reproduce:

  • create a new site with "jekyll new test-site"
  • start the server with "jekyll serve --watch"
  • in another console edit the _config.yml, change the site's title (you will notice in the server console: Regenerating: 1 files at xxx xxx ...done.)
  • refresh your browser

Result: no changes on the web page
Expected: if the site was regenerated (as console says), the edited configuration should apply (the new site's title should change)

Thx

@troyswanson
Jekyll member

Which version of Jekyll are you running?

@troyswanson
Jekyll member

Oh, whoops, you said 1.5.1. I believe this is a feature that is only on 2.0.0.

@parkr
Jekyll member
parkr commented May 6, 2014

The configuration file can't be re-read when using watch, because it contains things like source and destination. It could only work if it were actually like running jekyll build multiple times – as it stands, it's just running Site#process when a file changes instead of building a new site object.

@penibelst
Jekyll member

It is the intended behavior.

@mscharley
@penibelst
Jekyll member

That doesn't make it the right behaviour just the naive, easy behaviour.

Jekyll is a static site generator. The --watch option is limited by design.

@mscharley
@penibelst
Jekyll member

With more and more things being added to the configuration file

My configuration file has only 2 entries:

markdown: kramdown
permalink: /blog/:year/:title/

It’s enough for a full-blown static website with posts, pages and assets. No plugins. It’s not a pain for me.

@mscharley

It’s not a pain for me.

How nice for you. https://bitbucket.org/matthew-scharley/matt.scharley.me/src/d5531861bf9054537dd2fecacd873227ec1142c9/_config.yml?at=master

(And that isn't even the site with collections; that one's private though)

Have you considered you may be in the minority?

@mscharley

I could also throw default front-matter at that. Make the default layout actually be a default layout and provide sensible defaults for my sitemap.xml. There's lots I could do, but having to remember to restart jekyll each time I tweak and test things is not user friendly.

@penibelst
Jekyll member

Have you considered you may be in the minority?

This is a good question you can answer yourself first. The development time is much shorter than the usage time. If not, stop playing and start to create content.

@parkr
Jekyll member
parkr commented May 12, 2014

It used to be mostly infeasible but I think we can make this happen. @mscharley If you have time for a PR, I'd be happy to review it. This isn't a huge priority for me at the moment so I probably won't get to it soon.

@nternetinspired

Agree with previous majority sentiment. Really, how much time during a project build is spent toying with your global config? Observed behaviour is the expected result.

Set it and forget it.

@aldoforce

hey guys, sorry for making so much noise with my ticket. That was not my intention. As I user I just wanted to report a strange behavior on my console about something that every time I edit (_config.yml) the jekyll serve --watch console says "Regenerating..." when that's not really happening. I think that the fix is to put somewhere on the documentation _CONFIG.YML doesn't auto regenerate and that will be enough. In fact I opened two consoles, one with jekyll serve --watch, and the other with jekyll build when I edit the config.

@parkr
Jekyll member
parkr commented May 15, 2014

No I remember why we can't do this: if you change either source or destination, you're eff'd, so we said 👎 to this suggestion. Definitely use _data if you're using custom data. Otherwise, a quick ^C and restart should be 👌

@parkr parkr closed this May 15, 2014
@dergachev

Just want to weigh in that this is quite confusing to me too. As a new user, my workflow was as follows:

jekyll new source

make serve --watch &

# see my new default site on localhost:4000

make new_post # creates source/_posts/NNNNN-new-post.markdown

# see the new post appear on localhost:4000

vim source/_config.yaml    # start changing site title, to see if it works

# FRUSTRATION: changes to title not appearing on localhost:4000

I was frustrated enough with this to go looking through the whole issue queue to find a workaround, and finding this thread.

I personally don't think that the source and destination settings changing is a big problem, why can't you just reload them and handle it so the user behaviour would be identical as with the manual following workaround:

export SOURCE=source
export DESTINATION=destination
(cd $DESTINATION; python -m SimpleHTTPServer 4000 &)
while inotifywait -e close_write,moved_to,create $SOURCE; do jekyll build -s $SOURCE -d $DESTINATION; done

The above code was only briefly tested, but seems to work for me (at least after running apt-get install ionotify-tools).

@gka
gka commented Aug 30, 2014

Just experienced the same frustrating behavior as outlined by dergachev. Every new Jekyll user will run into this. If reloading the config is a no-go, I suggest to remove title, email and other actual site content from the default config to streamline the user experience. Why not add a separate _site.yml for all the site content and reload it properly in --watch mode?

@gka
gka commented Aug 30, 2014

Ha, take this jekyll!

> npm install watchy
> watchy -w _config.yml -- "jekyll serve --watch" 

:)

@orschiro

@gka

Fantastic solution using watchy. Thanks for mentioning!

@gilyes
gilyes commented Jan 23, 2015

@gka

Thanks for the watchy idea. In Windows I had to do

watchy -w _config.yml -- ruby "path_to_jekyll/jekyll" serve

as apparently watchy can only launch exe files, most likely related to this.

@fulldecent

I request that this issue be left open.

The current behavior is unintuitive and the reason it has not been fixed is because an elegant solution has not yet been found. This seems like an excellent example of something that should be kept in an issue tracker.

@davidsilvasmith

I'm chiming in too. _config.yml ++ for leaving this open.

@reustle
reustle commented Apr 4, 2015

This just bit me for a good 30 minutes, and it isn't the first time either. Definitely an unintuitive piece. While I understand we can't auto reload when a _config change is made, maybe we can log something in the console output when the config file has changed?

Regenerating: 1 file(s) changed at 2015-04-04 21:26:17 ...done in 0.045787 seconds.
Regenerating: 1 file(s) changed at 2015-04-04 21:26:51 ...done in 0.044885 seconds.
# NOTICE: _config.yaml has changed. Ctrl+C and restart to see changes
Regenerating: 1 file(s) changed at 2015-04-04 21:27:42 ...done in 0.045595 seconds.
@kleinfreund

maybe we can log something in the console output when the config file has changed?

This sounds reasonable. Something like Ignoring: _config.yml.

@reustle
reustle commented Apr 4, 2015

Yeah, something like that does sounds better.

Ignoring changes made to _config.yml

@lginter
lginter commented Jun 9, 2015

Please at least document it somehow; I wasted around 20 hours trying to get _config.yml to refresh.

@TWiStErRob

+1, at least a notification if not an auto-restart

@CarlJohnston

+1 for notification (or at least a comment near the top of _config.yml) to notify that server should be restarted.

@envygeeks envygeeks locked and limited conversation to collaborators Jul 5, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Something went wrong with that request. Please try again.