Video details

Guy Nesher - Automating your development process to ensure maintainable code | AngularUP 2021

Angular
01.19.2022
English

Trust no one - automating your development process to ensure maintainable code "Angular is a framework designed to enable developers to build fast, secure, and maintainable applications. But without ensuring the quality of the code, it is not possible to write maintainable code - and the Angular CLI does very little to help us. In this talk, we will learn how to use tools such as eslint, prettier, lint-staged, husky, and SonarQube to ensure your code is clean and well-written. Finally, we will look at what the future has in store with solutions such as the Rome Tools that will hopefully simplify our development process in the future." Guy Nesher -
Front end Team lead, Locusview "Guy Nesher is team lead in Locusview, specializing in JavaScript and related web technologies.
He divides his time between organizing events, speaking in conferences, and writing tech articles for InfoQ."

Transcript

Hello everyone. My name is Ganesha and I'm here to speak with you about some ways you can use to improve the development experience and streamline your development development process to hopefully create cleaner, more maintainable code. And this talk really shouldn't exist. This is something that should be obviously easy to make, but sadly with the world of JavaScript and TypeScript is not that easy. So here we are and hopefully you'll learn a few things that you've not been using in your code base and I'll be able to help you improve, even if just by a little bit your development flow. And let's get started. And I hope this line doesn't supply anyone here. Angular is a framework. We should all agree on that. And the problem with the fact that Angular is a framework is that we don't really have a clear distinction between what Angular does and what Angular doesn't do or what it provides and what it doesn't provide. And that's a little problematic because people who will follow all the correct guidelines by reading the Angular documentation can easily find themselves shooting themselves in the foot in quite a few places because Angular simply didn't tell them and didn't provide the tooling that it should really provide for any significant project. They do provide routing or routing, and they will provide a way to translate your application, which is great, but giving the basic capabilities of linking and making sure that your code isn't broken is something that Angular decided not to include. And we just missed out. And these problems become more complex when you realize that a lot of the cost of software development doesn't happen during the initial development phase. Even though this is where we spend a lot of our time estimating and arguing, it actually happens when you need to maintain your code and the mistakes that you made a year ago when you initially started the project will quite often come back to Hunt you. And I've worked in more than one company where there were pieces of codes that you just didn't touch because someone left the company and no one knows what's going on there, and we're trying to avoid that. I hope so. Before we dive into how I suggest we fix some of these problems, I will, of course, talk about myself. So my name is Gainesha. As I said, I work in a company called Locustville. It's a startup located in Italia Pitua. We're giving away the umbrellas, so please stop by and take an umbrella. And I also write for a magazine, an online magazine called Info Queue. It's a really nice magazine that writes about everything that's developer related. I write about web stuff, but you can find everything there, and I recommend stopping and having a look. Finally, there's no time for QA after the session, so either grab me outside if you have questions or contact me via the email or Twitter handle. I will publish the presentation on Twitter once I'm done simply because there's links to a lot of useful resources. So do keep an eye on. I'm going to stop by and start discussing or showing what Angular actually provides before we talk about how we can improve it, because Angular does provide a few bits of helpful designs. And the first thing that Angular provides, and it actually provided it from day one, is the Angular coding style guide. Did anyone here ever read the entire style guide raise your hand? Wow, that's like five people. Which is great. And it is why the Angular style guide is mostly useless now. Initially, Angular provided a tool called Tslinter piece of software that will validate that your code base adheres to this style guide. But sadly, about two years ago, TSA became deprecated and Angular decided to stop supporting linking in Angular, which means that we have no way of validating that any of our code actually adheres to the style guide that the Angular thing created for us. You can like it and you can dislike it. And I'll argue with whomever wants to argue about this, but it's gone. They do tell you you can use a communitydriven effort in order to implement this, and we'll talk about it in a minute, but they don't tell it anywhere that you're going to find out. I mean, if you're starting a new project these days, there's a very good chance you won't even know that Linting is a possibility that you're missing. And I'm of the opinion that if you agreed on a rule or made a decision but then made no effort to enforce it, that rule is absolute. And you can think about a lot of meetings you had as a development team where you agreed to write more unit tests, but then didn't. And then six months later, no one remembers the fact that you agreed to write more unit tests. Now, we don't have that problem in Locker view, but other companies I've helped some friends, and we want to avoid this. Right? So having Angular removed the only tool we have to enforce the style guide that they spent a lot of time writing is really a shame. Now, not everything is bad with Angular. I'm still using it. They did in Angular Twelve, turn on the street flag in type strip, which means that we have a much better type safety built in into Angular automatically. These days. If you've started the project before Angular Twelve, especially if it's a big project, it's going to be nearly impossible to turn on the street flag because you're going to get hundreds if not thousands of errors. Things like no implicit any, which means that you have to implicitly declare each type of your variables is something that you either did from the get go or never going to do. If you are interested in improving your type safety, you should be aware that a strict flag it doesn't actually do anything it just combines five or six different flags so you can turn them on and off manually to gradually add these capabilities into your system. So that's important. There's a link to show you which flags are controlled by the street flag. The goal of the street flag is to be future proof, so if tomorrow TypeScript adds new rules, they will automatically be added into the strict flag, and you'll just get them for free. But sometimes it's just too painful to do it yourself. Angular also provides the Angular Language Service, which doesn't prevent you from doing anything and does require you to usually install a plugin into your idea. But if you do, you get a lot of helpful comments content within your Angular templates, which is great, but not really enforceable. And that's it. I mean, Angular framework stopped here. You have nice autocomplete features within your templates, and you have better types of integration, but everything outside of these two things are on your head or shoulders, and it wouldn't have been that bad if people knew that there's a lot of tools out there that can help you, but most people don't. So let's start by talking about the first and most obvious rule that can help us, which is Esliint. Eslint is the replacement for TSLint. It's been around for ages. It's intended for JavaScript, but we now have a typescriptip parser that will help you use Eslimp on TypeScript. That's why Tslink became deprecated. And if you also want to use the Angular coding style guide, you can use the Angular plugin that will help you implement most of the existing rules back into your sleep if you just look at this, what used to be something that you got out of the box from Angler now requires that you install three different libraries that don't actually work together that easily. So Angular will work fairly good. If you are trying to migrate your existing Angular application, it will try to move the rules into the new system, and it will set up a basic rule set for the Angular coding style guide, but it won't add any of the default rules from Islam itself. And they also have some quirks, like they're using a rule that prevents or tells you to prefer arrow functions instead of regular functions, but forgot to install the plugin that does it, so you're just going to see arrows, so it's not really that simple. And of course, Eslit itself wasn't written for TypeScript, so there are some rules in ESLint and some plugins for ESLint that won't work in Angular projects because they're not supported by TypeScript. To get you started, I created a Gist, a piece of code that shows you the basic setup for this link. It includes all the default recommended settings, as well as the Angular rules and a few other bits and bobs that are needed to get everything running properly. So this process will only get you basically back to what Angular used to provide two years ago, but we can do better than that. The next tool that I'm going to recommend is something called Prettier. I'm not sure how many of you are familiar with it been around for a while, and it's one of those tools that you either really like or really hate. And what it does is that it will format your code, and it will tell you how to format your code, because it really doesn't care how you used to do it yourself. It's a bit annoying at first because your code base is going to look differently, but it does it really fast, and it will change your code base for you, which means that you don't need any developer intervention. It will automatically fix the code base into the correct format for you. And that's great because no one wants to have a build fail because someone forgot to add a space somewhere or use the single quote instead of a double quote. So if you're able to convince the developers in your team that this is good enough and it is good enough, half the world is using it, then start using it tomorrow. The one thing I would change is the line length 80 character is just silly. Go to 120 at least and it will solve half the things that annoy you. Now this looks great, but there's actually a problem because both Prettier and East Lint has conflicting rules, so if you try to run them, you'll get to a point where Pretty here runs, and then you get yes, Lint errors that your code is misbehaving, and you know that you didn't add the space there. It's because Pretty to edit and to fix that. There is yet another plugin that basically disable the Eslin proof that relates to Prettier, because that's an obvious thing to do. It's already included in the gist I created, so it should work. But nothing here is just straightforward and we haven't even started so far. We added two tools, really. We have a new Linter that basically emulates what Angular used to provide, and we have Prettier that will helpfully help us manage the code formatting. But we're not enforcing anything, which is rubbish, because if I just agree with the developers in my team that they run ESPN and pretend before every commit, it will happen at least 50% of the times, which isn't good enough for me. And we can solve it in two ways. We can put both Prettier and TSLint on Jenkins on our CI CD solution, but that's not really good enough in my opinion, because of two main problems. I tend to do a lot of commitment before I push it, and that means that I won't get feedback from Eslin up until the point where I do the build on our development servers, and that can take hours or days. And it's really annoying to finish a new feature only to realize there are tons of problems that I need to fix, and if we want to run Prettier on Jenkins, we also need to allow Jenkins to make commits into GitHub, because Prettier is going to change the code. And now we need somehow to provide a way for Jenkins to write that the new formatting into GitHub, which I don't really like. And the solution to these two problems is to move the process into the development machine itself and find a way that both Eslind and Prettier will run whenever you make a commit, which has been possible for quite a while. And the solution for that is GitHub's. I'm not sure how many of you are familiar with it. We'll get in there in the next slide. Guitar shouldn't be confused with GitHub actions, two separate things. Github basically allows us to run random pieces of code whenever something happens in our repository. You can set it manually, but it's not easy at all, and it has never been intended to use specifically for JavaScript, so there is a lot of configuration problems if you try to set it up directly. I did include a link to a nice tutorial if you're insistent, but most of us are using a different tool to do this, which is called Husky. Now Husky is great, but wasn't originally using Guitar. So if you are going to Google for a tutorial on how to set Husky, you are 99% sure going to get an old version of Haskey with bad configuration that will not work for you. So don't try that. But the modern Husky is excellent. It just wraps it hooks in a very convenient way. It supports all the existing key hooks. So we're going to use the pre commit hook in our use cases. And again, it's being used everywhere. It also has excellent documentation with the little star that I've added. Because if you try to run the install here, it's probably going to fail once or twice. The first thing is that NPM set script only exists in the most recent NPM, so if you try to run it with anything installed six months ago, this isn't going to work. And it doesn't do anything. It simply adds the prepare script with this code into package. Json, but you won't get any error. Npm will just tell you that it doesn't recognize the command, so you can fix that easily. But then if you try to run NPM, run Prepare and you're using Windows with Git Dash, it's going to fail as well. It won't tell you that it failed properly, it just won't run. And there's no easy way to fix that because Git dash has a problem with NPM and neither one of them is going to fix it anytime soon. So Husky can really fix it themselves. My suggestion is to move to Linux and Windows, or just use a Mac or just use Linux. Any one of these solutions will work if you still want to use Kitash, you'll need to go to the documentation site of Husky and they'll tell you how to manually set up Git hooks and the Husky integration. It's not great, but you'll have to do it. We're not done yet. This will only do the integration with Guidox, but we're not running anything. And in order to do this, we're going to use yet another library which is called Link Staged, which is, I think the greatest thing ever created. If you've ever tried to run ESLint or TS link on your code base, you will realize that it's a fairly lengthy process because you're linking the entire code base. And if you have a big code base and a lot of rules, this can easily take minutes. And what Lint Stage does is just look at the committed files and run leant against those files alone. And that makes a process that would take minutes, hopefully take seconds. But this isn't the best feature of Link Stage. It is, but it comes with an extra value. If I want to add a new rule into my code base in Eslink, I will instantly create hundreds of errors. Because this is a new rule, we haven't enforced it, and now the bid will fail until I fix the entire code base. And this is something that a lot of development teams can do. But if I use Link staged, then the Linter is only going to run on the files that are changed so developers can gradually fix those problems. And that allows me an easy way to integrate new rules into ESLint as they come in, as the team develops and we decide to adopt stricter rules. So this is great. And again, running it is super simple but doesn't always work. It uses a CLI tool called MRM that will read your package Jason and try to understand the setup you have in order to set up the integration correctly. In my attempt, it will correctly integrate with Husky, but not put the correct command within package JSON. So you still need to edit the Link staged with the relevant tooling for angular and TypeScript. Because we want to have Eslink running, you generally want to use the cash as it makes run faster and you want Eslin to fix whatever it can fix. You don't have to use this flag. You can ask Eslin to just show you the warnings, but if it can fix automatically stuff for me, I'd rather do that. And I'm also running prettier and tell it to write the fixes into the code base. Again. If Prettier can fix my layout for me, I'd rather prettier do it. And if we're able to do all of this successfully, hopefully the next time we're trying to make a commit, we will see the following piece of text that basically shows that we're running two pieces of code prettier Neslint and if Eslin finds an error, the commit fails. The code did not enter our Git repository and we can see exactly where the arrows are and what will stop them. And this is super helpful because this means that developers during the development process can see the errors and fix them without having to wait for the CI CD, and without having to rely on any third party programs that they have to install. Because if we look at the template language solution that Angular offers, it's great, but everyone has to install it here. Developers don't need to do anything. As soon as they install your application, they have everything set up for them, and you can know that they won't be able to add any problematic code into the code base. Now it is important to say that we've only discussed the default basic rules. There are dozens, if not hundreds of rules and plugins that you can add, and we're not going to argue about them because this is a contented area and every person will use the exact rules that they want. I do have a few links to the rules to available plugins and to some example configuration, so you can see how different companies use ESLint. There are some really interesting plugins out there, including one that will check the code complexity of your functions, and if a function is too complex, it will prevent you from merging it. And that's great, because if you have a function with 100 lines of code, you probably need to break it and breaking it. Doing development is fairly easy. Fixing a bug there a year later is not. So if you're going to start using the setup, I suggest start with the basics, but I do recommend adding additional rules as time goes by. A few more things It's really important to understand that the setup I'm showing here doesn't physically prevent malicious developers from circumventing our set of rules, and they can edit package. Json and delete GitHub that we set up and you should fire them. But until then they will be able to add the code into your code base. It's okay for me. I just don't think that if someone decides to actively work against you, the problem is your code base. But if that's not your decision, then you can add prettier and Eslind back on top of Jenkins, so you'll have another round of validation there, which is harder for the developers to convent. Two other things before we finish for the day, and this is less about Linting and more about your pool request process. How many of you are using a file called Code Owners? A few GitHub and bitpucket. And all the big providers now support a funnel file called Code Owner, where you can decide that certain files or directories in your code base are managed by specific individuals or teams. And when you do that, you can make sure that the person who does the pull request approves the pull request is the person that you've listed in the file. And this is great because especially if you have a big team with people that have better understanding of specific pieces of code, you can make sure that only these people will have proved changes on that piece of code. So this is super helpful. It's really easy to set up. It has nothing to do with the development process. This is only to do with the pull request process, but it's really helpful to prevent problems. The second thing that I want to tell you about is something called the Roam tool chain. If the fact that we had to install seven or eight separate libraries that did not quite work well together with each other seems a little unreasonable, that's because it is a little unreasonable and there is an active attempt to solve this by creating a single set of tools that will do all of the work for us and more. The wrong toolcharian chain was making good progress up until about a month and a half ago, at which point they decided to write everything in Rust, which means that it'll run a lot faster. But I have absolutely no idea when it's going to be available, which is a little sad, but do keep an eye on Rome. It will come out I guess by the end of next year and it will simplify a lot of the problems we're seeing by making everything happen in a single set of tools. If it works correctly, I can't promise anything. The second thing is that if you are at all active with the Angular community, I will urge you to raise the issue of how complicated it is to set up Linting and prettier all the modern tool set that a developer really needs to be using in order to make a significant application with Angular. People are expecting to see this with Angular. The fact that we don't know that these things are missing and that these things exist and there's nowhere in the documentation of Angular that tells you, hey, listen, you should do this. It's a really big problem and it exists in Angular specifically because we are promoting Angular framework and this is what frameworks do. I don't care about the form controls. I care about making sure developers build their first app and not have it fall apart six months later. So do reach out to whomever you have contact with in the Angular community and complain because that always helps and they sometimes do. Listen, that's it for me. Thank you very much. The timer has not been run.