Deployment of Angular2 App to GitHub Pages

Angular 2, or just Angular as it’s now called, is new, exciting and constantly evolving.  While it’s great to be on the cutting edge of a JS framework, the process can be extremely frustrating at times…

I’m currently working through “Angular 2 – The Complete Guide“, an Udemy course by Maximilian Schwarzmuller.

I wanted to take a quick break to test how much of the course has sunk in, so I went back and rebuilt my Random Quote Generator App from the Free Code Camp frontend projects.  I picked this because it was fairly simple and I wanted to build an Angular project from creation to deployment without investing too much time.

Building the project was relatively quick and painless, which is a testament to Max’s course mentioned above.  You can see my GitHub repo here (and the app finally deployed here).  Given that it’s a static app (i.e. no backend), I figured GitHub pages would be a good place for deployment.

This is where the headache started…  One of the inherent problems when working something like Angular, that’s constantly changing is that many of the resources become irrelevant and incorrect very quickly (this one, no doubt, included).

I found multiple blogs and Stack Overflow answers, some written only months ago, claiming that you could deploy to GitHub pages with the following one command:

After much frustration, and multiple attempts at rebuilding and redeploying, I found that the deploy command was removed from the angular-cli.

So the command written above certainly wouldn’t work.  The functionality, however, is available through the angular-cli-ghpages npm package.

Before we proceed on how to use the angular-cli-ghpages package, there are a couple assumptions being made in this process that will need to be met if this is going to work…

First, I’m assuming that you have Node.js installed on your computer.  If not, visit the Node.js site for instructions for download.

I’m also assuming that you have an Angular app, associated with a GitHub repo, written and ready to deploy…  If not, go create something and commit it to GitHub!!

With those assumptions out of the way, input the following in a terminal to install the npm package globally:

Once installed, you’ll need to build the app.  In the app’s folder, run:

This will create a dist folder that contains the compiled code for your app.  Obviously, you’re going to want to change the above command to include your GitHub username and the repo name.

Then deploy:

or just:

You can find all the options at the angular-cli-ghpages site.

This will deploy a new branch to your GitHub repo called gh-pages branch. Make sure you’re using this branch as the source for your app.  You can find/change this option under the GitHub Pages section of the Settings tab of your repo.

It might take a few minutes for the app to show up on your page, be patient!

That’s it for now, I hope this was able to help.


Prefer Heroku?  Here’s a good article if you’re having trouble deploying a static angular app to heroku.  The title says Vue, but it works great for angular now that they’re using webpack…

The MEAN Stack – A New Direction for Crooked Code!

It’s been about 8 months since I began the Crooked Code blog…  And so far it’s been a great experience!

While the overall purpose for writing the Crooked Code blog has been, and will continue to be, helping others learn to code, most of the posts fall under one of two major themes…

The first of these themes has been articles covering Algorithm Scripting Challenges in the Free Code Camp curriculum. Two of the most popular of these posts, based on pageviews, have been Symmetric Difference and Map the Debris.

The second major theme has been tutorials on JavaScript, including the Rubber Ducking Series I started a couple months ago based on (but not affiliated with) ‘You Don’t Know JS’.

Where to go from here??
Where to go from here??

While I plan to continue adding JavaScript tutorials, particularly the Rubber Ducking Series, I’m planning on putting a temporary hold on new posts covering Free Code Camp algorithms.

As you may have heard, Free Code Camp has announced they are adding a major expansion to their curriculum. A look at the current map of the beta version shows that many of the advanced algorithms will be supplemental to the main program.

Because of this, I’ve decided to wait until the beta is released into production before I continue writing up more algorithm challenges, as I have no way of knowing which challenges will make the final cut.

I am, however, very excited to announce that I’ve decided to add a third major theme here at Crooked Code – Angular 2 (ng2) and the MEAN stack.

Angular 2

I’m doing this for several reasons…

First, about 90% of my focus lately has been on learning Angular 2.  It’s the first JS framework I’ve learned, so the process has been a long one, and judging by many of the comments I’ve seen throughout the FCC community, I’m not the only one on this journey.  Which brings me to my second reason…

The final release of ng2 is so recent, many of the tutorials and videos out there are a mix of earlier release candidates and the final release all mashed together…

This causes some major confusion in building a working ng2 app, particularly in how to structure the project.  So I hope to shed some light on what I’ve found and save others some of the time I’ve spent (and continue to spend) making sense of it all.

MongoDB, express, Angular2 and NodeJS
MongoDB, express, Angular 2 and NodeJS

Further, I plan to highlight how the ng2 frontend framework ties into the rest of the MEAN stack.

Now that I’ve spent some time digging into Angular 2 on a deeper level, I’m planning on using my previous experience with Node, Express and MongoDB (with Mongoose) to build larger full stack apps.  I think this will be a great opportunity to share what I’m learning with the Crooked Code community.

That’s all for now,




Block Scope and Hoisting – An Exercise in Rubber Ducking

This is a follow up to  ‘Intro to Scope’, previously posted here at CrookedCode.  It’s part of our rubber ducking series, where we’re attempting to work through some of the more difficult parts of JavaScript using Kyle Simpson’s book series, You Don’t Know JS, as a guide.

If you want to know more about the project, check out this post.  If you’re thinking to yourself “Where does this guy get off thinking he can explain this stuff better than Kyle Simpson?”, check out the disclaimer here. Otherwise, read on…

As the title suggests, this post will cover block scope versus function scope, particularly as they pertains to varlet and const. I’d like to start with the concept of hoisting, however, as I think it’ll help understand the rest of the article.

WTF is Hoisting?  (And Do I need a boat to do it?)

Consider the following:

The question here is will “Will this get logged?” actually get logged to the console even though hoisted is declared after it  A) has a value assigned to it and B) gets logged.

The answer is yes, “Will this get logged?” is logged to the console.

You’ve also probably seen examples of functions getting invoked before they’re even declared.  Have you wondered why that works too…

Something like:

The above snippet will log ‘Henry’ to the console.

Both of the above examples work because of hoisting.  As we mentioned in the previous article, JavaScript is a compiled language.  Part of the compilation step is finding all the declarations (variables and functions) and associate them with the appropriate scope.

This part actually occurs first, before the code is executed.  Therefore any function or variable declared in a given scope will be available throughout that scope.

In the first example above, var hoisted would have been ‘hoisted’ to the top of scope within the hoist() function.  So when the JS engine comes across hoisted = a and searches for a variable called hoisted in the lexical scope within the hoist() function, it’ll find it!

One more note on hoisting…

Don’t confuse declaring a variable with assigning a value to a variable, even if that happens in the same line of code.

var name = 'Henry'; is seen as two statements by the JS engine, var name; and name = 'Henry';. The declaration is hoisted, the assignment is not…

If you think this is just semantics, consider the following:

Someone with a tenuous grasp on scope might look at this snippet of code and think there are a couple possibilities…

“That’ll probably be a ReferenceError because a is declared after it’s logged..”


or if they’ve heard of hoisting….

“Maybe it’ll print ‘Henry’ to the console because a is hoisted within the printYourDogsName function”

Nope again…

The actual answer is that the snippet logs undefined.  If you think back to the last article, undefined (as opposed to ReferenceError) means that the JS engine found the variable a (because it was hoisted), but a was undefined (because the a = name assignment didn’t happen until after console.log(a).

Ok, enough about hoisting… I think that should give us a pretty good grasp on how things work.  For more detail please refer to YDKJS.

The Complexity of Scope

I hope my previous article, along with what’s covered here, has given you a pretty good understanding of lexical scope and how it works in JavaScript.  So why did Kyle Simpson feel the need to devote an entire book to scope and closures?

You know the old saying ‘You don’t know what you don’t know…”?  Well, there are several special circumstances that are covered in ‘Scope and Closures’ that I won’t be addressing here at Crooked Code of which you should be aware.

One such concept is using scope to hide access to variables.  I plan to touch upon some of this in a future article on Modules, but in the meantime, YDKJS covers it here.

You can also read about the specifics of scope as it pertains to function expressions, including Immediately Invoked Function Expressions or IIFEs, here.

The final topic you should be aware of that I won’t be covering in this article is closure.  Simpson devotes an entire chapter to closure and I highly recommend reading it.

I’ve read it a couple times and my pulse still quickens a bit when someone mentions closure (I’ll be writing a rubber ducking article here on closure in the near future to solidify the concept in my own head).

Now on to Block Scope

We’ve discussed previously that JavaScript uses functions to define scope.

This was, for the most part, entirely true until ES6.  Among the changes in ES6 were the keywords let and const, which provide us ways to declare variables with block scope.

The only difference between the two is const declares a constant, which can’t be changed once assigned a value.

Before we get into what block scope is, there’s a key note to remember when dealing with let and const.  They are NOT hoisted within their block of scope.  This means that you must declare them before you use them or it will result in a ReferenceError.

Now, what’s block scope?  Simpson tells us a block is commonly a {...} pair. So think for loops, if statements, etc..  You can even create your own block of scope by enclosing code in curly brackets.

Block scope can be useful in several key ways…  Consider the following:

In this example, as I’m sure you can figure out by now, 10 (not 42) would get logged to the console.  This is because i would be hoisted to the scope within the redundantI function.  So when the engine comes across the var i = 0 statement in the for loop, it will already see the i variable and use that one.  Now consider:

This snippet would actually result in 42 getting logged.  Why? Because let created a new i variable for use ONLY in the for loop!

I realize this example is pretty idiotic and you’re probably thinking to yourself “This guy is effing nuts… I’d never make that mistake in my code…”.

I know you wouldn’t make a mistake like that, but think about functions that are 100+ lines of code with a couple additional functions nested within.

If you’re using a variable for the sole purpose of controlling the for loop, wouldn’t you prefer to keep it out of the overall scope? Wouldn’t it be nice if you could use the variable in the loop, then have it go away?  let enables that…

Simpson also discussed using block scope to enable garbage collecting when you’re handling large amounts of data.  It’s a pretty interesting concept and can be read in the garbage collection section of Chapter 3.

The final point to mention regarding the use of let concerns its use in loops.  Simpson points out that, not only does let bind the variable to the body of the for loop, but it re-binds the variable to each iteration of the loop.

This may seem trivial, but when you consider closure it can be a very useful behavior if you understand it enough to use it properly.  I’ll cover this in more detail in my article on closure, but you can read about it now in the YDKJS section called ‘Block Scoping Revisited’.

That’s it for now…  If anyone’s still reading, thanks for taking the time.  I hope I was able to straighten out the code for you.