There are tons of great new quality-of-life features you can use in 3.3. Three key things you might want to try:
1. Themes can now ship static & dynamic assets in an
In Jekyll 3.2, we shipped the ability to use a theme that was packaged as a gem. 3.2 included support for includes, layouts, and sass partials. In 3.3, we’re adding assets to that list.
In an effort to make theme management a bit easier, any files you put into
/assets in your theme will be read in as though they were part of the
user’s site. This means you can ship SCSS and CoffeeScript, images and
webfonts, and so on – anything you’d consider a part of the
presentation. Same rules apply here as in a Jekyll site: if it has YAML
front matter, it will be converted and rendered. No front matter, and
it will simply be copied over like a static asset.
Note that if a user has a file of the same path, the theme content will not
be included in the site, i.e. a user’s
/assets/main.scss will be read and
processed if present instead of a theme’s
See our documentation on the subject for more info.
Want a clean way to prepend the
url in your config? These
new filters have you covered. When working locally, if you set your
baseurl to match your deployment environment, say
relative_url will ensure that this baseurl is prepended to anything
you pass it:
baseurl is set to
"" and therefore yields (never set to
A result of
relative_url will safely always produce a URL which is
relative to the domain root. A similar principle applies to
It prepends your
url values, making absolute URLs all the
easier to make:
site.url is set by the development server
When you run
jekyll serve locally, it starts a web server, usually at
http://localhost:4000, that you use to preview your site during
development. If you are using the new
absolute_url filter, or using
site.url anywhere, you have probably had to create a development config
which resets the
url value to point to
No longer! When you run
jekyll serve, Jekyll will build your site with
the value of the
port, and SSL-related options. This defaults to
url: http://localhost:4000. When you are developing locally,
This happens by default when running Jekyll locally. It will not be set if
JEKYLL_ENV=production and run
jekyll serve. If
any value except
development (its default value), Jekyll will not
overwrite the value of
url in your config. And again, this only applies
to serving, not to building.
A lot more!
There are dozens of bug fixes and minor improvements to make your Jekyll experience better than ever. With every Jekyll release, we strive to bring greater stability and reliability to your everyday development workflow.
As always, thanks to our many contributors who contributed countless hours of their free time to making this release happen:
Anatoliy Yastreb, Anthony Gaudino, Antonio, Ashwin Maroli, Ben Balter, Charles Horn, Chris Finazzo, Daniel Chapman, David Zhang, Eduardo Bouças, Edward Thomson, Eloy Espinaco, Florian Thomas, Frank Taillandier, Gerardo, Heng Kwokfu, Heng, K. (Stephen), Jeff Kolesky, Jonathan Thornton, Jordon Bedwell, Jussi Kinnula, Júnior Messias, Kyle O’Brien, Manmeet Gill, Mark H. Wilkinson, Marko Locher, Mertcan GÖKGÖZ, Michal Švácha, Mike Kasberg, Nadjib Amar, Nicolas Hoizey, Nicolas Porcel, Parker Moore, Pat Hawks, Patrick Marsceill, Stephen Checkoway, Stuart Kent, XhmikosR, Zlatan Vasović, mertkahyaoglu, shingo-nakanishi, and vohedge.
Full release notes are available for your perusal. If you notice any issues, please don’t hesitate to file a bug report.