Differences from Jekyll

Ruby Jekyll

Jigyll targets Jekyll compatibility, but it is a separate implementation and some behavior differs. The categories below are generated from the same compatibility metadata (_data/compat.yml) that powers the callout at the top of each affected page and the badges in the sidebar — one source of truth, three surfaces.

Replaced

These topics work fundamentally differently in Jigyll.

• Installation — Jigyll ships as a single Go binary — install via Homebrew, Scoop, Docker, or the install script, not RubyGems/Bundler. There is no Ruby toolchain to set up.
• Plugins — There is no extensible plugin system — plugins are Go code compiled into the binary. A fixed set of popular plugins is emulated; list them in _config.yml under plugins:, not a Gemfile.
• Upgrading — Upgrades come through your package manager (Homebrew, Scoop, Docker, the install script, or go install) — there is no Bundler or gem update.
• Command-Line Usage — new creates a blank site directly; its themed form requires a Git URL. There are no doctor or import commands. Jigyll adds plugins, render, routes, variables, and benchmark. serve renders in memory (nothing is written to disk) and live reload is always on.

Modified

Mostly the same as Jekyll, with specific differences.

• Assets — Sass is always on but Liquid is not processed inside Sass files, output is always minified, and only the sass_dir option is honored. CoffeeScript is not supported.
• Collections — collections_dir and custom sorting (sort_by, order) are not supported — collection folders live at the source root, and only posts is sorted (by date). Everything else works like Jekyll.
• Configuration — A wrong YAML type for a supported key is a build error. markdown:, liquid:, and most sass: and kramdown: options are ignored — only kramdown's toc_levels is honored. Front-matter defaults match by path prefix, not glob. Caches live in /tmp/jigyll-$USER, not ./.sass-cache.
• Data Files — Reads .yml/.yaml/.json/.csv files in _data, including namespaced subfolders — but no TSV. CSV parses into rows of strings, not header-keyed maps.
• Front Matter — Malformed YAML always fails the build (strict_front_matter is ignored), and files without front matter are copied as static files unless the jekyll-optional-front-matter plugin is on. Defaults scopes match by path prefix, not glob.
• Documentation — Jigyll is a partially-compatible clone of Jekyll written in Go. Most Jekyll concepts carry over, but not every feature is implemented — pages that differ are flagged like this one.
• Liquid — Undefined filters and tags are build errors; undefined variables render as empty. find and find_exp are missing. Jigyll adds Shopify-style money filters (money, money_with_currency, …) that Jekyll doesn't have.
• Pagination — jekyll-paginate (v1) is implemented: paginate and paginate_path split the posts list across copies of the index.html they point at. Page URLs are directory-normalized (/page2/, not /page2), and jekyll-paginate-v2 features (pagination: block, category/tag pages) are not supported.
• Permalinks — Global permalink: pretty also applies to implicit ordinary HTML pages; other global styles and custom global patterns apply only to posts. Unknown placeholders are build errors, and several date placeholders (:week, weekday names) plus the weekdate style are missing. Custom front-matter keys work as placeholders.
• Posts — Categories and tags come only from front matter — the singular category:/tag: keys and directory-based categories are ignored. --future keys off the filename date, and excerpt_separator is global-only.
• Rendering Process — Markdown is rendered by goldmark, not kramdown: raw </> is treated as HTML, header IDs are generated differently, and there are no smart quotes. Kramdown's {:toc}, $$ math (passed through for MathJax/KaTeX), heading attribute lists, and markdown="1" blocks are supported; standalone ALDs are not. Sass files skip Liquid entirely.
• Static Files — Front-matter defaults never apply to static files — only the five built-in metadata fields are available, so filter on path instead of custom flags.
• Directory Structure — No .jekyll-cache, .sass-cache, or .jekyll-metadata — the build cache lives in jigyll-$USER under the system temp dir, and jigyll serve renders in memory without writing _site.
• Themes — Themes resolve from a local _theme/<name> folder or Bundler. remote_theme supports only pinned GitHub owner/repository@40-character-SHA archives; branches, tags, URLs, and full plugin behavior remain unsupported. Theme _data, theme config, and theme.* variables are ignored.
• Variables — jekyll.version reports the Jigyll version, page.dir and the theme.* variables don't exist, page.next/previous are posts-only, and site.related_posts is simply the ten most recent posts.

Jigyll-only

Jigyll additions with no Jekyll counterpart.

• GitHub Pages Compatibility Roadmap — This page tracks the work and verification gates required for explicit GitHub Pages and Ruby Jekyll compatibility profiles.
• Differences from Jekyll — This page has no Ruby Jekyll counterpart — it aggregates every known divergence from the compatibility metadata that powers these callouts.

GitHub Pages

GitHub Pages adds a pinned Jekyll 3.10 runtime and managed plugin set. The Ruby Jekyll differences above therefore also apply to Pages unless a Pages-specific behavior is called out below.

See the current plugin baseline for all GitHub Pages dependencies, their versioned reference environment, and the verification work required before a profile is supported.