Troubles in Deploying to Heroku

I’ve deployed to Heroku before, but every system has a novel way of deploying. This system deploys a minified, uglified, optimized chunk of code that’s ready to get out there and make the world a better place.

This part of the readme from the generator describes how to go about deploying to heroku, so I won’t get into that. Instead, I’ll discuss times when the production code was different than the development code because of the processing that happens before deployment.

First, my production code had some strangely sized text and I realized that in the development code, I had changed opening <h4> tags to <h3> tags, but I hadn’t changed the closing tags. My local system worked this out, but the minifier didn’t know how to handle it and the errors made themselves visible on the production page.

When I had followed all of the instructions, a few things weren’t working in my app. Most noticeably, 2 images were not rendering on the page and I was getting logs in the console that said the resources were not available. One image was working and I inspected the element to see that it had a different name than the one I had given it. A string of characters had been pre-pended to the file name in the src property of the <img> tag - the image I had named bookclub.png was now caled acc78a2b.bookclub.png in the html. I checked the resources and I found that there was, in fact an image with this name and that there were similar resources for all of the images that weren’t working. I checked back with the html to see that the file names in the srcs in the <img> tags had not changed.

During that minifying/uglifying process, the images had been optimized by Grunt’s imagemin function (for more details on that, you can find imagemin in the Gruntfile and see node-modules/grunt-contrib-imagemin/tasks/imagemin.js). The /dist/public/images optimized files all had new names with a prepended string like the example above. Somehow the imagemin was changing the name of some of the html src attributes but not others.

I spent a good deal of time lost in the gruntfile and in searching stackoverflow for reasons that imagemin wouldn’t work for some files.

After deciding to look more carefully at my own code, I was able to troubleshoot the first problem relatively quickly. The image was not actually in html. It was referenced in a scss file as a background-image attribute. Either the processing to change src references does not go through style sheets or the processing on style sheets interfered with proper renaming. I brought the image out into html and sized it appropriately so it filled the background.

The second image was a mystery. It was in html and the file name GitHub_logo.png was not being changed to match the name of the new file 52a9aeae.GitHub_Logo.png. Wait, did you catch that?

In my development html I had:

<img class="github-link" src="assets/images/GitHub_logo.png">

but the file was actually named GitHub_Logo.png. In my local environment, there was no case sensitivity, so my typo was glossed over unnoticed. Unfortunately, when the minifier/uglifier was looking through the code for src="assets/images/GitHub_Logo.png", it found no such thing because it WAS case sensitive. This was a quick fix that took a VERY long time to find.

When I decided that the wording in my navbar needed a new font, I referenced a google font in a <link> tag on my index.html file as is described on the google fonts instructions.

<link href='http://fonts.googleapis.com/css?family=Alegreya+Sans+SC:400,700' rel='stylesheet' type='text/css'>

When I deployed, the font had fallen back to the default font and looked terrible.

Fortunately, StackOverflow was there for me this time. This article addressed my question even though the poster had a different problem. The solution provided gave me the alternative I needed. I went to http://fonts.googleapis.com/css?family=Alegreya+Sans+SC:400,700 and copied that code into my stylesheet.