Building a JavaScript Development Environment

Course Overview
Ah, JavaScript. It's so easy to get started. Wait, no it's not, it's overwhelming. Now sure, today, more of us are writing JavaScript than ever before, and if you've been coding for long, you may recognize the value of testing, linting, bundling, transpiling, automated builds, and more, but all too often, we ignore many of these items. Why? Because setting up a solid JavaScript development environment is so much work. The list of choices is so long and complex that it's hard to know even where to get started. Hi, I'm Cory House, and I'm here to help. I've been building rich web applications in JavaScript for over 15 years now, and frankly I'm tired of starting from scratch. So in this course, I propose a solution. What if your team had a powerful, rapid feedback development environment? What if every time you started a new project, you had a solid foundation that supported automated testing, bundling, linting, transpiling, error logging, and so much more out of the box? That's the goal of this course. Let's stop starting from scratch. Let's build a JavaScript starter kit so your team can rapidly get started and enjoy all the benefits of a modern, powerful, and automated development experience. A great JavaScript development environment makes doing the right thing the easy thing. In this course, we'll make it happen.

Editors and Configuration
To get things started, we need to make a few key baseline decisions about our tooling. So in this short module, let's begin with an obvious point: we need a JavaScript editor. So let's quickly look at some options, and I'll help outline what you need to be looking for in a solid JavaScript editor today. Then we'll wrap up this short module by assuring everyone on our team uses the same critical editor settings, like spaces versus tabs, line endings, and more, by using a standard called editorconfig. Alright, let's get started.

Package Management
These days virtually every popular language has it's own package manager, yet JavaScript soldiered on for many years with no compelling package management story. Thankfully these days we have a variety of JavaScript Package Managers to choose from. In this module, let's begin by exploring the list of Package Managers we have to choose from. We'll ultimately go with npm for this course which probably didn't surprise you much and we're going to set it up for our demo project. We'll wrap up by looking at a couple interesting services that will scan your packages for security vulnerabilities. This way we can help protect ourselves from known vulnerabilities in the packages that we choose to install. Okay, let's get started with Package Management.

Development Web Server
If you're working in JavaScript, chances are you'll want to run at least some of your code in the browser. So in this short module, let's quickly consider a few interesting options for development web servers. We'll configure our web server so it's automatically started as part of our development process and opens our application so we can view our results immediately every time that we hit save. And what if we want to quickly share our work and process with others? Well, we'll look at some interesting and useful services for making that quick and easy.

Automation
Hey, we're developers, so of course we don't want to do things manually. Automation is a necessity to assure that development builds and related tooling are integrated and utilized in a consistent manner. If we do our job right, all the team will benefit from rapid feedback along the way. So here's the plan. In this module we'll review the options for automating our development environment and builds, and after discussing the options I'll introduce npm scripts which is the automation tool that I recommend for gluing all of our tooling together in an elegant and repeatable manner.

Transpiling
People have complained about JavaScript for years. And justifiably so. It languished with no innovation for a full decade. It's a wonder it survived such stagnation. Yet, with the advent of ES6 in 2015, the language has finally grown up in a big way. And annual releases mean that we can look forward to more goodness every year. This is great, but it's also one of the many reasons transpiling has become so common. In this module, we'll begin by look at JavaScript's history and its future. This will help set the stage for understanding why transpilers are so desirable today. And why we're likely to continue using them for the foreseeable future. Then we'll take a glance at the long list of interesting transpilers to consider and finally we'll configure my recommendation for transpiling today, Babel. All right, let's begin by taking a short walk down memory lane.

Bundling
These days, when you write JavaScript, it likely needs bundled up for usage. Why? Well, if you're a JavaScript developer, it's important to understand that NPM packages use the commonJS pattern. node can handle this just fine, but browsers don't understand it. So you need to bundle NPM packages into a format that the browser can consume. But bundlers aren't just for apps that run in the browser. You may use a bundler to package any JavaScript into a single file. Or strategically into separate files, for different portions of your app. Imagine you've created an app with five separate pages. A powerful bundler can intelligently create separate bundles of JavaScript for each page. That way, the user only has to download the relevant JavaScript for the first page on initial load. This saves bandwidth and speeds page loads. Finally, remember that bundlers aren't just for the Web. You may want to use bundlers if you're coding in node as well, since node's require is slow. But bundling your code for node, you can compile away the require calls, which can often improve performance. So in this module, let's begin by considering the various module formats available in JavaScript, including AMD, CommonJS, UMD, and ES6 modules. Then we'll discuss the various bundlers to consider, like Webpack, Browserify, Rollup, and JSPM. And we'll close out this short module by implicating ES6 modules and bundling them up with our NPM packages via my suggested bundler, Webpack.

Linting
You shouldn't have to keep track of your team's entire list of coding standards in your head. As much as possible, we should automate the task away. And we should be notified immediately when we make a typo. JavaScript linters can deliver on both of these concerns. Today's linters are so powerful that they can catch many errors at compile time. It's wonderful finding out that you made a mistake the moment you hit Save, rather than waiting until run time to hunt some cryptic issue down. So in this module, we'll begin by asking why do you need a linter at all? Then we'll quickly consider the linting tools available. We'll spend the rest of the module discussing the most popular linter, ESLint. We'll discuss the long list of configuration approaches to consider. And we'll set up linting to run all our rules every time that we hit Save. Simple enough. Let's get rolling.

Testing and Continuous Integration
It's a shame how uncommon automated testing and continuous integration are in JavaScript and I believe it's because people don't see a clear picture of how to get quickly started. Since JavaScript has no built-in opinions on handling testing, you need to spend a lot of time browsing the web and investigating strategies before you can get rolling. So in this module, I'd like to help outline the landscape to help you understand the key decisions that you need to make. Because if you're new to automated testing, just picking your tools and deciding how to use them is a major hurdle. So we'll begin by reviewing six key decisions that you need to make, including testing frameworks, assertion libraries, helper libraries, and more. And once we've clarified our testing stack, we'll jump back into the editor and set up our test environment and write our first example tests. We'll close up this module by discussing continuous integration services so that we're notified immediately anytime someone breaks the build and we'll set up two different continuous integration servers. This is a big topic with a lot of ground to cover, so let's get rolling.

HTTP Calls
As we saw in the first module, JavaScript is eating the world, and when it comes to protocols, HTTP is eating the world too, virtually every JavaScript application that we've built today makes HTTP calls. So in this module, let's explore the libraries for making HTTP calls via JavaScript. These libraries are essential for making Ajax calls in modern applications. Then we'll shift our focus to Mocking HTTP Calls. We'll discuss why mocking is useful so we can code without hitting any actual APIs, rapidly try different response shapes, code offline and much more. And we'll wrap up by considering various approaches for doing mocking HTTP calls. We'll implement a compelling mock API that generates realistic fake data and simulates a database using a simple generated file full of JSON. This module is about making our development environment interact with the real world, and these days, the world talks HTTP, so let's dive in.

Project Structure
It's been a long road, but we're well on our way to enjoying a seriously robust, comprehensive, and luxurious JavaScript development experience. But we still have two major pieces left to consider in these final two modules. In this module, let's explore how to put all this to use by discussing project structure. In this short module, I want to begin by explaining why I believe your team starter kit should include a demo application. Then, we'll move on to discuss three specific project structure tips to keep in mind as you're building, not just your demo app, but any future JavaScript app. Alright, let's begin with my sales pitch on why your team needs a demo app.

Production Build
Of course our application isn't very useful until we actually prepare it for production. So in this module, let's create an automated production build. We'll cover a variety of considerations including minification to speed loads, with source maps generated to support debugging in production. Hey, let's be honest, you and I both know this happens. We'll setup dynamic HTML handling for production specific concerns, and cache busting to ensure that users receive the latest version of our code upon deployment. We'll setup bundle splitting so that users don't have to download the entire application when just part of it changes. And finally, we'll setup error logging so that we know when bugs sneak their way into production. Now this sounds like a lot of work, but as you'll see, this moves fast. Alright, let's dig in.

Production Deploy
Congratulations on making it to the final module, we're finally ready to discuss the last missing piece, Production Deployment. We'll begin this final module by discussing the merits of separating the user interface from your application's API, into completely separate projects. We'll briefly discuss the wide variety of cloud hosting providers. Then, we'll create an automated deployment for both the UI and the API, using popular cloud service providers. We'll wrap up the course by discussing approaches for keeping existing projects updated as your starter kit is enhanced over time. And I'll quickly provide some tips for further inspiration as you start designing your own development environment. And I'll close out the course with a short challenge. Alright, let's dig in, and wrap this up.