I was working on my Jekyll site recently and all was working as expected in my setup. When I was finished with my work, I bumped the Gemfile.lock to fix a security vulnerability (thanks GitHub security notifications! ) with a version of Kramdown. After the Gemfile bump, however, my Jekyll setup stopped working correctly.
Now, whenever I make changes to the code while bundle exec jekyll serve is running, the auto-generation doesn’t appear to be working (i.e. no changes occur in my browser, and yes I’ve verified that I’m working at localhost:4000 ).
If I restart my server, after the restart the changes show up in my browser (so I know the initial jekyll build is working to recognize my changes), but any subsequent changes once server is running again are not recognized.
Looking at the server output I see that incremental build is disabled, and I can also verify that Auto-generation is enabled according to the server output.
Strangely, something that is new in the output since this has started occurring is all this output with block in _process_changes, block in new, etc:
Comparing your Gemfile.lock to a freshly installed one for Github-Pages, I see various differences (ActiveSupport 5 vs 6, Github-Pages 207 vs 209, etc). Maybe rebuilding the lock file completely would help? (i.e. delete Gemfile.lock and run bundle install).
For my Github-Pages based sites, I don’t commit the lock file because the gems used by Github-Pages are not fixed and so local gems need regular updating to stay in sync.
From the screenshot, it looks like Ruby 2.3 is being used (../rbenv/versions/2.3.3/...). In theory, Jekyll 3.x should work with that version, but Ruby dropped support for 2.3 in 2019 and Github-Pages isn’t being tested with anything earlier than 2.5.
Possibly upgrading Ruby to 2.5 or higher would help?
I tried building your site under Ruby 2.3 (Docker) and I can produce a nearly-identical error when the _includes directory (not contents) is modified. I.e. touch _includes/causes a scan DIED error and after that Jekyll-serve hangs.
@ashmaroli thanks, pinning Listen ver seems to have resolved the issue.
@chuckhoupt thanks, I upgraded my local Ruby ver to 2.7 just to be safe.
For my Github-Pages based sites, I don’t commit the lock file because the gems used by Github-Pages are not fixed and so local gems need regular updating to stay in sync.
Now that I think about it, I’m not sure if I need the github pages gem anymore since my site is no longer hosted on GH Pages, but is on Netlify. Would I be safe to just remove the github-pages gem?
Technically, one would only need the github-pages gem only if they’re deploying via GitHub Pages. So it is safe to remove.
However, do note that since the GP gem has many runtime_dependencies, they automatically get included in the bundle and if used under the jekyll_plugins group in the Gemfile, the dependencies get loaded automatically during a jekyll build as well.
So, if you can be certain that all plugins needed for your site are explicitly listed in both the Gemfile and the config file, removing the GP gem is absolutely safe.
The only gem I have is Jekyll I think but its also in local/bin as a standalone. I don’t have a gemfile in any of my jekyll site roots either. Does Jekyll need gems?
Jekyll runs fine as a stand-alone, global Gem, but it limits you to using a single version* of Jekyll and related gems (plugins, themes, etc). If you have multiple sites that require different versions of Jekyll (and related gems), then using Bundler can save you from manually juggling global Gems (i.e. “gem version hell”).
For example, until recently I had sites that required Jekyll 3.1, 3.9, and 4.1. Using Bundler’s Gemfile/Gemfile.lock mechanism was the only sane way to work with them. As soon as you have two or more sites of different ages (i.e. with incompatible gems), Bundler becomes a necessity.
* Different global Gems can be accessed by version number, but it is awkward. e.g. jekyll _3.9.0_ build
If you absolutely have only one gem, (i.e. jekyll), then you will have trouble.
The following link is the Rubygem page for Jekyll: https://rubygems.org/gems/jekyll
The list of 14 gems under the heading RUNTIME DEPENDENCIES has to be present in your system for Jekyll to run all aspects of itself.
Therefore, when an end-user runs gem install jekyll (the recommended way to install jekyll without using a Gemfile), Ruby downloads those 14 gems and installs them along with the jekyll gem.
Similarly, if any of those 14 gems have runtime_dependencies of their own, then those gems too shall be downloaded and installed.
So on and so forth.
oh right - forgot. I have those dependencies of course. I don’t use sass or the jekyll watch but they are there. I just never see them or get any nudges to update anything.
) with a version of Kramdown. After the Gemfile bump, however, my Jekyll setup stopped working correctly.
).
