Warning: this is a meandering, intermediate level screencast in which we look at the code that powers a build process for a site. We don’t write any code.
A “build process” is all the stuff that happens between the code you write and code that goes out to a live website. We’ve talked before about using Grunt for this. Sass is processed, assets are combined, minification and optimization happens, etc. There are endless things that a build process can do for you.
I’ve been working with Katie Kovalcin on building a new personal site for her. It’s an experiment for both of us in learning new processes and trying new stuff. In this case, I’m using Jekyll for the first time, and I’m automating an SVG system for the first time.
At the time of the screencast, I’m right in the middle of it all, but I got the build system working smoothly so I figured it was a good time to share that. I always think that’s a good time to share – right at the moment where something clicks for you.
Things going on:
- Grunt runs all the tasks.
- The site is being built with Jekyll. Meaning it processes the layouts and content into full web pages. When content or layout change, Grunt runs the Jekyll build.
- Jekyll also runs the local server.
- Sass is the CSS preprocessor. When a Sass file changes, Grunt runs the Sass complication. Then Grunt runs Autoprefixer on the result. Then Grunt runs the Jekyll build again to make sure all new stuff is usable by the processed site.
- The site uses an SVG system. For icons, but also the logo, and who-knows-what-all else by the end of it. The SVG files are kept all separate in an “svg” folder. When any of them change, Grunt runs the svgstore task to process them all together. Then Grunt runs the Jekyll build so all the current SVG is available to the site.
- Because this a repo on GitHub, and GitHub Pages support Jekyll, we can automatically get a live, hosted version of this site. We can also point another domain at this site.