Chapter 6. Gulp for different environments
This chapter covers
- Incremental builds and build caches
- Debugging original files through sourcemaps
- Environment specific switches and noop blocks
In part 1 of this book you learned how to create a good, solid build setup we referred to as the local development environment. This setup allowed the automation of repetitive but common tasks, as well as a development server along with the ability for automated iterative builds.
If you take a good look at the artifacts of your build, you’ll see that the result is production-ready code. JavaScript and CSS are optimized and minified, and all your dependencies are wired up, ready to be published on a production web server. One huge advantage in having such a result is that you can be sure that the code you deploy is the same code you built and tested earlier when developing locally. There are some shortcomings, though. Imagine that you find a bug in your application; JavaScript no longer executes and the developer tools of your browser spit out an error message. With optimized, production-ready code, you’ll most likely find something like what’s shown in figure 6.1.
Figure 6.1. The minified and concatenated output of your main.js file inside Chrome’s developer tools. The code is obfuscated and nowhere near the original source you used when developing.
