Transcript from the "The Anatomy of a Build System" Lesson
>> Scott Moss: I'm going to show you guys a working example of a minimal Hello, World build system that you can use for Android 2. And then you're going to build one from scratch, and it's gonna hurt, it's gonna suck, you might walk out and leave, tell Mark you're never coming back but you're gonna know how to do this, all right.
[00:00:25] This is like learning to build an app and stuff, it's really great if you have some code there and you go and do some problems but I think a build system, you just build it from scratch. You just have to know how to build it from scratch and you gotta figure this stuff out, run into the resources, which is the best way that I've learned how to manage the build systems.
>> Speaker 2: So you don't recommend using a starter kit?
>> Scott Moss: No, I do recommend using a starter kit after you already know what's going on. We're gonna use the starter kit. This build system that you're gonna use now, we're not gonna use it. We're gonna throw it away. But, it's gonna get you familiar with it, so when you use the starter kit, at least you'll know what's going on when an error's thrown.
[00:01:00] Like I don't know what's throwing this error. Is it typescript, is it webpack, is it, I don't know what, who's throwing this error. This is gonna help you get familiar with that. So you can get familiar with your environment. Any questions? Okay, let's hop right into it then.
[00:01:20] Cool, so if you want, you can try to copy some of this, but just challenge yourself, don't worry about any of this stuff, you are going to build it from scratch. I'll leave it up as a reference. Probably push up to get help, too. So what we're gonna do is I want everyone, it's finally working.
[00:01:38] I was trying to get this linter to work for like forever and it's finally just kicked in. Sublime is so trivial, I don't know. So what I want everyone to do is just make a new folder, make a new repo, right. This is brand new. This is nothing to do with what you guys are doing with Luke, this is completely separate.
[00:01:52] If you feel like you already got modules or you feel like you already got the build system down, you all know what you're doing. I don't know, then I guess you don't need to do it. But I'm guessing that it's pretty tough. It was tough for me. So just make a new folder and then inside that just make a new app folder.
[00:02:08] And just put root.ts, and just write some TypeScript stuff in there, something that isn't gonna run in the browser, something that needs to be compiled. In my example, I just made an interface and a class to infamous interface. That's all I do. That's obviously not gonna run in the browser.
[00:02:23] It obviously needs to be built. So that's what I put there. You can copy what I have if you want. But at minimum that's what you'll need for this.
>> Scott Moss: And then what we're gonna do is we're just going to, I'm just gonna walk you through. Again, this is very minimum.
[00:02:43] This is not like a production level built system. It's gonna be way more than this, but this is enough to get started and really all you need to get going. And then you can add, depending on your project and what you're doing or what your team's needs are, you can add and take away things.
[00:02:59] But we're just gonna cover the full spectrum of the stuff that you're gonna be using. So first let's talk about probably the most important part, which is the bundler. Again we're using webpack. So the way webpack works is you just create a webpack.config.js on the root of your repository, webpack.config.js.
[00:03:21] All right, and really, all that does is just exports a module, an object that has this config. There's a lot of unimportant stuff in here, but really, the only stuff you really need to know about as far as getting it started, is the entry. Because unlike loading script tags in the browser where there isn't a single point of entry there, you're just loading everything up, in a module LAN there's a single point of entry and everything's a tree.
[00:03:46] There's a dependency tree of modules. So you need to say, hey, where's the root? In this case, it's that file you just made, that's the root.
>> Scott Moss: So that's important. Also this resolve block here, this is telling webpack that, hey, these are the types of files that you can expect to see.
[00:04:03] Just letting you know, by the way, just in case, also the other important thing here is the output, where to place the bundled files. So the path, which is the build folder, which you do not have to create, webpack will create for you if it's not there already, and then the name of the bundled file.
[00:04:21] This bundle.js which is what most people use in webpack, but it can be anything you want.
>> Scott Moss: And then the meat and the potatoes are right here, this module object, which who here has used Goat? Okay, so this is pretty much like a plugin place where you would do your goat plugins.
[00:04:44] So loaders are like plugins that transform your modules. So we have this loader called awesome-typescript-loader whose job is to transform any file that has a ts extension on it, excluding these files.
>> Scott Moss: Obviously you don't need to put this here because you don't have this in your repo, but I just wanted to show you an example of what exclude does.
[00:05:08] So this is just a regex. You can put file name, you can put whatever you want here, but a regex will obviously be more greedy and capture the stuff that you really want. And then this loader is an MPM module that was loaded. So this isn't just some random thing that I installed.
[00:05:21] You can also just exclude the loader part and it'll still work, you don't have to put -loader. It's kind of like back in the days of Grunt where Grunt didn't use require, instead you just had to give it a name and it figured it out. That's what this thing is doing.
[00:05:36] If you go look in my node modules, awesome-typescript-loader's right there. So it's coming from there. So it's not explicit like Gulp where you have to require it. It's being a little implicit here. So yeah, that's saying awesome-typescript-loader. If you look at this documentation it's Java just to compile your typescript for you.
[00:05:55] That's it. But I only wanna do it on these files. Cool, and then this devServer here, again this stuff is not really important as far as getting started because you can really use whatever you want to serve it. But if you wanna use the webpack devServer, this is just an option that's saying, hey, here's your API fallback.
>> Speaker 3: Just a quick question on, any reason for using AwesomeTypeScript versus TS Loader?
>> Scott Moss: I was using TS Loader for a while but then AwesomeTypeScript, I heard about it, and it was just awesome. So I switched over to it. I mean, I will just show you why I use it and then whoever asked that question can probably see for themself.
[00:06:32] The first line that it says is the best TypeScript loader for webpack.
>> Speaker 4: So you have to use it, it's the best one
>> Scott Moss: That's why I use it, it's the best one. Yeah, that was it. So if somebody comes out with another one and said it's even better than the best, I'll probably switch over to that one.
>> Speaker 3: What are they gonna do when they come out with the awesomer TypeScript loader?
>> Scott Moss: I don't know. I don't know what's gonna happen.
>> Speaker 2: The bestest? [LAUGH]
>> Scott Moss: And I've had issues with the TS loader, where I had to do some manual configuration like silencing different errors.
[00:07:07] It was just really fine grain whereas Awesome TypeScript kind of just knows what I want, and it's here, man, here, I know what you want here. Whereas TS Loader is I don't know. So yeah, Awesome TypeScript, but TS Loader will work, too, I've used it before, it totally works.
>> Speaker 3: For this example you're going through right now there's no repo to start from UI.
>> Scott Moss: No, there's no repo to start from. This is from scratch.
>> Speaker 6: But it's not cuz you already typed most of this.
>> Scott Moss: I did, and I said you shouldn't be copying this.
[00:07:35] But if you're not confident about yourself, you can totally copy this but it's still probably not gonna work. Most people are still gonna run some error, that's the whole point. I want you to write us an error, just be like, what? What's going on? That's the whole point.
>> Speaker 7: Why are you using webpack to run the compiler instead of, say, Gold 4 MPM?
>> Scott Moss: Good question, I love Gold. I use Gold for everything. I actually use Gold with webpack. So the reason I'm not doing it is one, I don't like putting everything in MPM scripts.
[00:08:06] It's just my opinion, but you totally could. Most of these tools here have command line options that you can just pass MPM scripts and just run it, boom, easily. Gulp, Gulp is awesome, too, obviously. And there's also plugins for that. But what about modules? That's the biggest thing about webpack.
[00:08:23] It's going to poly fill CommonJs for you in the browser whereas Gulp and MPM Scripts won't by default. You gotta build that stuff yourself. So that's the biggest reason right there, it's just the modules. And because I'm already using webpack for modules, I might as well use it for everything else, too.
[00:08:38] But Gulp is still useful because yeah, webpack is great for doing everything related to your files and assets, but what about like one-off tasks that you need, like a deployment task or a create documentation task or something like that? I usually use Gulp for that. And so what I do is I have Gulp orchestrate webpack for me.
[00:08:58] That way I always interface with Gulp and Gulp handles everything. But there are arguments against that, whereas like, webpack can build docs, too,. Yeah, it can. It can pretty much do anything, but, again, it's your choice. I use them both and it works fine. So, this is the bundler.
[00:09:14] And then typing's, do not copy this, this was generated. Remember, typing's is just a JSON file that's just going to tell your build to, hey, these are the type of definition files that I'm aware of and I'm gonna give you really cool tools to use when you use these files, pretty much.
[00:09:34] You almost never have to come into this file and type stuff in manually. You use the command line tool typings. Do --help and that's really all you need. It will tell you exactly what to do. Tslint is exactly what it sounds like. It's a linter for typescript. I don't know what everybody's using here, but I'm sure most major IDEs and text editors have a linter for typescript.
[00:09:55] And if you don't, just switch over to one that has one like Atom or Sublime, WebStorm, I think even Visual Studio Code has one now. So you should be totally fine with that. Another TS file, that's like three of them so far, it's crazy, all these TypeScript files.
[00:10:13] This third one here is to how we configure the compiler. So what is actually reading this? Well if you go to webpack and look at the Awesome TypeScript loader, this Awesome TypeScript loader is using the typescript command line tool, which is using this TS Config adjacent file. This is, what, how would you know that?
[00:10:31] Yeah, so this is how you configure the compiler. You're giving it options like, what am I targeting? Obviously, we're targeting ES5 because you want this to run in a browser. We can change this to target ES6, and it will compile down to ES6. But then it wouldn't work in the browser, right.
[00:10:47] So we're gonna target ES5. What modules do we wanna use? There's different types of modules out there that I talked about. There's systemJS which is what JSPM uses, which is actually the standard, which is the real thing. There's requireJS. There's so many other modules. And if you're using JSPM you can make your own module system.
[00:11:06] So there's literally an infinite amount of different type of modules you can use. It's crazy. But we're using CommonJs. Which is not requiredJS. Although CommonJs use is required. So, if you got those two mixed up, they're not the same. Okay, it took me a while to figure that out a long time ago.
[00:11:22] And then all this other stuff that's really not that important. This is just configuring the compiler. Again, you don't actually have to touch this either. There is a command line tool for TSE. If you don't have that, you can MPM install globally TSE. Then you do --help on that and it'll also set this up for you.
>> Scott Moss: And that's really about it. So, once you get, again, the only stuff you really need set up is this webpack thing here and then a file to build it. All this other stuff, I do recommend getting it set up though. You need to learn how to set up.
[00:11:57] Because the beauty of TypeScript is the tooling. So if all you have is a bundler set up and you are not really getting the autocomplete and the linting and the recommendations and the pathfinding, then what's the point? So I do recommend setting up this other stuff and that's what the point of this exercise is, is getting your environment set up so you feel comfortable with it and figuring out all the tools.
[00:12:16] Like I said, everybody's on a different environment so there's gonna be different things but most of it usually has these four files, the ts config which configures a compiler, the lint service configures a linter. Typings which configure where are type definition files are located and our webpack. And this is what typings looks like.
[00:12:39] If you use the typings command line, and so when you start downloading stuff, It creates this folder and just adds all this stuff in here, all types of crazy stuff. And then it will link them up to your typing JS. I just deleted everything out of mine to confuse you all.
[00:12:55] So that's why mine is empty.