 Hi everyone, I'm Brian. I'm a software engineer at Square and today I'd like to tell you about how you can take advantage of linting with ember in order to ship better code faster I've worked on a variety of product teams over the years and like many of you I've shipped all sorts of cool features and I've written and reviewed a lot of code During that time, I also noticed a lot that could be improved about the development process such as developers oftentimes making the same mistakes again and again And so I began to focus more on the infrastructure or platform side in order to tackle many of these recurring issues Linting, which is a rule-based static code analysis tool, turned out to be a superpower for tackling many of these problems Now whenever you work on Automation or related tooling, you need to be mindful of the situation turning out like this xkcd comment Where developing the automation can actually take as long as the original task But my goal with this talk is to convince you that Linting is something that will save you time, not cost you time And that even writing your own lint rules is very approachable and something that you should add to your toolkit So we're going to be looking at some real bugs caught with linting and other examples of how linting can benefit you how ember integrates with linting and Finally we'll dive into writing a lint rule of our own So first let's look at this real bug that I've caught with linting This is an ember component which displays a list of milestones and whether or not they've all been completed But there's a bug in this component such that the property here will always return false See if you can spot the bug Well, it turns out we were missing a return statement in this callback Pretty common mistake to make Given the different ways of writing functions in JavaScript And now you may be thinking that TypeScript could help out here TypeScript is definitely an incredible tool for catching mistakes and logic issues And I definitely recommend using TypeScript alongside linting But in this case TypeScript alone would not have caught the issue Technically we're allowed to have an implicit return value of undefined in this callback as that will simply be considered falsely And so TypeScript will not report a type error with this code Instead this is more of a syntax pattern that often indicates a mistake And this is something that we can use linting to detect If you have the esun extension enabled in your IDE You could have received immediate feedback about this issue from rules like array callback return Which would have noticed that the callback in this array function was either Missing a return statement or should have been converted into the array for each function Another lint rule called no unused expressions would have noticed that the expression here Milestone.completed is useless the way it's written and thus we're likely forgetting to do something with it Let's look at some other benefits that come from linting I really appreciate how linting can not only Help to enforce best practices, but it can also teach us about them In fact when it comes to onboarding a new member to our team It's really magic how the tooling can now do much of the work of teaching best practices for a given code base or framework In this code sample, I'm showing a simple ember component that is not doing a great job of following ember octane best practices First we prefer to use glimmer components over classic components in ember octane Second we prefer to use native javascript classes over classic classes Kind of going along with how ember has been moving away from ember specific syntaxes that are no longer necessary And third there's a rule to help guide us away from using the the tag name on the component because glimmer components no longer provide A wrapping element for that tag name linting is terrific for accessibility Here I have an html image tag and I'm actually forgetting a key attribute on it, which is the alt text attribute That's needed for screen readers to describe what this image depicts So i'm trying to fix the issue here by adding some alt text, but It turns out that there's still an issue in my code base I'm also using the no bear strings lint rule To ensure all of my strings are translated for different languages and countries another aspect of accessibility I'll likely need to use a translation helper to fix this linting can also help us with tightening security We want anyone using triple curlies in their templates to be informed that they may be allowing unsafe html to be injected into their page Now as always if someone has a legitimate reason for Writing code like this then they can always disable the lint rule on this particular line of code Ideally including a comment about why they need to disable the rule Let's look at how ember uses linting eslint is the core javascript linting framework and Really the great part about it is that it's extensible and so we use it for our ember linting plugin as well Which I'll talk about in a moment There's a node linting plugin which can help us ensure we're avoiding deprecated or unsupported node apis There is a q-init linting plugin, which is new in ember 3.26 And this one is great at detecting test assertions That may be written incorrectly or in a confusing fashion There's ember template lint, which I'll talk about in a moment And there's also prettier which is new in ember 3.24 And can really help us to auto fix all of our code formatting and simply eliminate the bike shedding and knitting that comes from differing code style preferences So let's dive into esn plugin ember. That's the javascript linting plugin for ember, which is uh Pretty mature at this point. It has over 60 recommended lint rules The latest version comes with ember octane linting enabled by default And this is really powerful because we can use linting Alongside code mods to help us modernize existing applications and kind of guide them towards ember octane paradigms As we saw earlier there are rules for things like encouraging glimmer components native classes track properties And we've also had a focus on robustness in recent versions of this plugin Uh, we always want to minimize false positives so that developers can trust the linter And finally we've updated our rules to support all the exciting new javascript syntaxes that have come out in recent years ember template lint is ember's custom linter for handlebars templates This one also has a sizable number of lint rules And the latest release also comes with ember octane linting enabled by default There's also a neat new feature for setting due dates on linting violations something that can be useful when you have hundreds of violations to address And finally there's a new feature for linting arbitrary file types including plain html files So now let's walk through writing our own lint rule Because if you frequently see developers making the same mistakes You should consider whether you can write a lint rule to solve the problem Once and for all and help guide developers in the right direction Don't just fix it once Fix it for the long term Let's implement a simplified version of the ember no get lint rule This is a rule that ember uses to encourage developers to migrate from the older ember object get function to the New javascript es5 getters which are a cleaner and more standardized way for accessing properties This is going along with how ember Wants to reduce its weird wear and also reduce its learning curve I like to follow test driven development. So when I write a lint rule, I'll typically start out by writing the test cases First we can write out some disallowed test cases things that should be Flagged or caught by the lint rule and here I have the basic form of this dot get with my property name Then we'll also write out some allowed test cases Some variations that we do not want to flag because they're using unrelated functions unrelated objects Or they're simply too complex for us to handle right now All right, so now let's focus in on this disallowed code sample I'm going to paste this into a website like like astxplorer.net To generate the abstract syntax tree And now let's walk through how this abstract syntax tree on the right corresponds to this single line of code So first we have a call expression which is like a function call Inside that we have a member expression this dot get On the left side of the member expression we have a this expression And on the right side we have an identifier named get to the function name Finally, we have a string literal arguments inside the function call Keeping this abstract syntax tree in mind Let's write the actual implementation for this lint rule ESLint provides us a convenient framework for visiting nodes of different types And so on the left here, I have a visitor function for visiting every call expression or function call in a javascript file Inside the visitor function, we'll use an if statement to Check for the particular tree structure that we're looking for And if we find it we can at that point flag a lintine violation So inside this if statement, I'm first going to check for a member expression as we saw before On the left side or the object side of that member expression, I'm going to check for a this expression And on the right side or the property side, I'm going to check for an identifier Identifier named get And then a single function call argument Which is of type literal And that is a string that does not include a period because for now we're ignoring nested property paths So if the linter gets this far then We found the particular structure that we're looking for and We can report a violation with an error message indicating the problem and potentially suggesting effects It's not pictured here, but we could also at this point provide an auto fixer function to automatically correct the code Something that is incredibly useful when we have Hundreds or thousands of violations And that's it It really wasn't that scary writing in our own linteral In fact, we could largely fit the core functionality in a dozen lines of code on a single slide Now we can decide where to publish the new lint rule If this rule was for some reason specific to our own Codebase application or company we could create our own linting plugin for it But ideally for a Generic lint rule like the one we've just written we can contribute this back to an open source linting project That way we can all clear our minds of this issue for good and get back to shipping our application So now it's your turn to pick a common nits or other mistake that keeps coming back To haunt your team and to try writing a lint rule to address it You'll also of course want to make sure your IDE is highlighting and auto fixing linting violations for you And you'll want to consider researching and installing any other relevant linting plugins for your codebase I've included a handful of my favorite linters for you to check out here But there are still hundreds or thousands more to choose from Thank you and happy linting