preloader

Using Hugo Pipes to Bundle Scripts


Hugo is pretty forgiving. If you are already familiar with web design, there isn’t much pain involved with working with the existing templates available. It’s time to experiment.

Here are a few notes from the video

Starting a new Hugo site is fairly easy. Once the Hugo is installed and ready to use, drop into the directory and create a new site. In this example, we are also installing the somrat theme.

$> hugo new site newsite
$> cd newsite
$> git clone https://github.com/Somrat37/somrat.git themes/somrat

Next, we want to move the assets from the example site into our root directory. If you are new to Hugo or web design in general, it’s good to start with a working site. You will no doubt break things during your experimentation. Instead of being totally lost, the error messages that come up will give you some direction on how to fix the site.

$> cd themes/somrat/exampleSite
$> cp -R * ../../../
$> cd ../../../
$> hugo server

Once the hugo server is running, you’ll be able to access the new site in your browser at http://localhost:1313. As you make changes to the templates and save the files, the site will either continue to work or an error message will display. Review the error, fix the problem and repeat.

In order for us to engage Hugo Pipes we need to move the style sheets and JavaScript from the static directory into the assets directory. This is because the commands we will use to join the scripts together are only designed to work with files in the assets directory.

The logic here is that the files in the static directory are not intended to be manipulated by Hugo. Files in the static directory are copied into the public directory as is when the site is generated.

$> cd themes/somrat/static
$> mv plugins ../assets    

Now that we’ve moved the assets, the site is broken. If we take a look at the config.toml file located in the site’s root directory, we’ll notice where the style sheet link references are being stored. We’re not making any changes here. Taking a look at the config.toml will give you some insight on what the template is using to create the site.

[[params.plugins.css]]
link = "plugins/owl-carousel/owl.theme.default.min.css"
[[params.plugins.css]]
link = "plugins/text-animation/text-animation.css"
[[params.plugins.css]]
link = "https://fonts.googleapis.com/css?family=Rubik:300,400,500,700,900&display=swap"

Now lets take a look at the template file responsible for looping through each of the style sheet references. In this case for the somrat theme, it is located at:

newsite/themes/somrat/layouts/partials/head.html

Here is where the template loops through each of the css entries in the config.toml. Each time a loop occurs, a new link line is painted.

{{ range .Site.Params.plugins.css }}
<link rel="stylesheet" href="{{ .link | absURL }}">
{{ end }}

Now we’ll add a few lines. In this example below, we start out by creating an array variable called $cssBundle. In this new empty array, we will be grabbing each of the links as noted in line 17 below. Next we are adding the newly acquired files to the array.

You’ll notice in line 14 we are excluding offsite links. This is because we don’t want to manipulate offsite code. That would be dangerous. Instead, we will print those links by themselves in a separate line.

Once our $cssBundle array is carrying a copy of the raw data from all our style sheet files, the information is outputted to css/bundle.css in line 21.

You’ll notice in line 17, we are minifying or condensing each file that is read in. This is extremely useful. In line 21 we are also fingerprinting the new file stored at *css/bundle.css”. This gives the bundle.css file a unique name each time we make changes to the template or any of the scripts. This will help prevent cache issues in the future.

12
13
14
15
16
17
18
19
20
21
22
{{ $cssBundle := slice }}
{{ range .Site.Params.plugins.css }}
{{ if findRE "^http" .link }}
<link rel="stylesheet" href="{{ .link | absURL }}">
{{ else }}
{{ $cssFile := resources.Get .link | minify }}
{{ $cssBundle = $cssBundle | append $cssFile }}
{{ end }}
{{ end }}
{{ $cssBundle := $cssBundle | resources.Concat "css/bundle.css" | fingerprint }}
<link rel="stylesheet" href="{{ $cssBundle.Permalink | absURL }}">

Now for the part I missed in the video.

We are bundling only the script files themselves into a single file. Some libraries we use come with additional assets, like Font Awesome. We will need to copy those back into the static directory.

Since the bundle.css file that we created will be placed in the public root directory called css, we’ll also need to make sure that any static assets go in the same directory.

$> cd themes/somrat/static
$> mkdir css
$> cd ../assets/plugins/fontawesome
$> mv fonts ../../../static/css   

Once the code is in place and we’ve addressed any typos or errors, take a peek at the source code. You should notice something similar as in the example below. Instead of a series of css files being called, we now call a single file called bundle.css. This should help with increasing page speed, especially if your template has a lot of assets.

<link rel="stylesheet" href="http://localhost:1313/css/bundle.5a781c68b31a93c2f719e913a2857e2693c9c9a19d912e76a1068762fe70a0ca.css">

We’ve been working a little with the new website locally. Let’s go ahead and generate the actual site files needed for the Internet. During this process, we can further minify (or condense) the HTML code that gets created by Hugo.

$> hugo -D --minify

This wasn’t intended to be an exhaustive tutorial of Hugo Pipes functions. It should give you a good idea of what you can do with Hugo and how much flexibility there is to making changes.


tags:  hugo  optimization  web development