 Microsoft replaced the long-deprecated TS Lint tool with ES Lint in the SharePoint Framework 1.15 release of June 2022. I know it was a little while ago, but this also involved revamping the default coding rules applied to all new SharePoint Framework projects. But many of the rule configurations are quite opinionated, and in my view, they're quite oppressive. This change raised a bunch of questions from many developers and students of my courses, including Michael, one of my newsletter subscribers, who responded with some challenges that he faced with one of his projects. So in this episode, I decided that I would offer some guidance on how to approach build time errors that you get triggered with ES Lint. I also explained how to modify the rules in your project and selectively disable rules within specific parts of your project. Hi, I'm Andrew, and if this topic interests you, please hit that like button below the video. It helps you reach more people just like you and grow this channel. And if you're new here, consider subscribing to my channel with the button below the video to see when I publish more videos for Microsoft 365 and Microsoft Azure full stack developers. And check out my bi-weekly newsletter where I talk about the same topics and share the most important news in the Microsoft 365 and Microsoft Azure space for full stack developers delivered straight to your inbox. Let's begin by understanding Linter's and SharePoint framework projects. TypeScript compiler enforces rules including things like no implicit any, no unused parameters, and no unused locals. Linter's were originally created to improve code quality and catch errors before compilers could perform many of these checks. But nowadays they're more commonly used for to establish coding standards. Linter's work by applying rules to your project using a configuration file. Now some rules support configuration such as adjusting the settings for the rules or specifying whether it should be treated as an error or a warning. Now if an enabled rule produces an error or finds a match in your code, ESLint is going to throw an error exit code. And in the SharePoint framework, the build tool chain first runs ESLint followed by the TypeScript compiler. Now the compiler takes precedence over ESLint. How should you handle ESLint rule warnings and errors? Well first, identify whether you're seeing a linted warning or an error or if it's a TypeScript compiler error. So I'll show you that first we have our project here that has a clean build and doesn't report any ESLint warnings or errors. So what I'm going to do is I'm going to add something that's going to trigger one of these errors. And so now when I run, you're going to see that I'm going to get an error here and it talks about the fact that I failed the dot notation. And that's what a warning looks like. Let me show you what an error looks like. Now I'll rebuild it and now we're seeing an error pop up which we're failing an error saying that there's something that's declared but it's not being used. Now there's a difference between the two messages. The first one, the dot notation, is from ESLint while the second one, TS6133, is from the TypeScript compiler, also known as TSC. Now to learn more about Linting and compiler warnings or errors simply search for them in Google. For the two examples that I mentioned above you can learn more about the dot notation rule on the TypeScript ESLint website and about TS6133 by simply searching Google. So in this case here you see it's ESLint warning and what it's saying is that with the dot notation rule that I failed it's saying that it's better to write it out as using the dot notation. So it says it would have been better if I would have said styles.hello world instead of putting it in the brackets and using it as like an indexer because it's easier to do type checking and to make sure that value's there. If I type it as a string I got a pretty good chance I can have a typo. The second piece that we saw here is the TypeScript error and what it's saying is that you can't declare something and then never use it. That's just you shouldn't have that kind of code. Just make sure code dirty is the extra stuff that's there that's not necessary. Well what if you don't agree with either one of these rules? What if you have your own standards for your organization? Well you can customize these rules both ESLint rules and the TypeScript compiler rules. To configure the TypeScript compiler settings you're going to use the included TS config file that's located in the root of the project. For example for the one we were just looking at it was no unused locals. So this piece right here this is by default is set to true. I could have set this to false but it defaults to true. But how do you configure ESLint? Let's examine the ESLint configuration and manage the various scopes in which it's found. Now all configurations for SharePoint Framework projects are defined in this ESLint rc.json file. To configure the rules for an entire project you can make a change in this ESLint.js file. This makes it easy for organizations to maintain specific coding standards across all of their projects. And by using a CINCD process you can ensure that every project follows the same standards. For example the configuration for the dot notation rule in the previous warning I showed you is the following. So what does this rule say? Well the first item in the array is going to refer to the rules severity. And in this case a severity level of one means that the rule should be just treated as a warning. While a level of two indicates it's an error. In a level of zero that's going to disable the rule. Now the second item in the array is the configuration of the rule. And in this case the allow pattern. That's an optional regular expression string that permits the use of a bracketed notation for property names that match a specific pattern. And to give an example the warning could have been avoided if the property hello world had been prefixed with an underscore. Now this approach works well for a project. But what if you need to selectively disable rules within your project? So perhaps you want a rule to apply to your entire project. But then there's this one specific case within a file that you prefer this rule not apply or you can't figure out. This can be accomplished using some special code comments. So to disable rules for a file within a project add the following to the top of the file. So what I'm going to say is in a code comment say eslet-disable and then with a space I'm going to put the name of the rule that I want to turn it off. And now you'll see when I build my project. Eslet doesn't report that error. You can also disable a rule for an entire code block by using a TypeScript comment to disable and then turn around and re-enable the rule right afterwards. So what I'm going to say is I'm going to surround my existing line of code that's causing the error. I'm going to say eslet-disable the dot notation and then I'm going to turn around and say enable the dot notation. So I'll start with my existing one just to simplify it. And I'll come down and find out where our error is. I'll put it in right here and then I'll turn right around and I'll re-enable it. And now when I run it you'll see that our rule is still not being caught. And then you can also disable a rule just for a single line. And you can do that by just adding a comment right before the line. So what I'll do is I'll remove our enable line and then I'll say eslet-disable-next line and it will still disable it. Or I can just do it on the same line that I want to disable by putting the comment at the end of the line and just having the command say something like eslet-disable-line. So how should you approach linting rules and warnings? Well let me give you my recommendations for these. First of all, don't panic and don't treat rules as absolute. Just because you fail a rule doesn't necessarily mean that you've got to fix your code. Perhaps your code is just fine as is and the rule is being too specific. Or maybe the rule simply doesn't work for your particular scenario. You may need to determine whether or not you're doing the right thing. It's also important to distinguish between compiler errors and linting errors and warnings. Just remember, the default rule configurations are set up for a reason. Someone decided that they represented generally accepted coding standard or one that they believe was important. But in my opinion, you shouldn't treat Microsoft's ESLint rule configurations as the ultimate authority. You have the final say and you can define what's acceptable for your project or your team or your organization. Take the time to develop your own personal, team or organizational standards and define them in your own eslint.js files. Make sure that these standards are used for all of your projects going forward. How would you best prefer to disable eslint rules in your projects? Do you have a question about using eslint in your SharePoint framework projects? Let me know by dropping a comment below and let me know if you want to see more videos about eslint and SharePoint framework projects. And if so, make sure you include what you'd like to see. If you liked this video or you found it useful, please give me a thumbs up. It helps me grow the channel by reaching more people just like you. And if you haven't already, subscribe by smashing that subscribe button below the video so you'll see when I publish more videos for full stack developers on Microsoft 365 and Microsoft Azure. And again, let me know if you want to see more videos about eslint and SharePoint framework projects. And like what? I'm Andrew Connell. Thanks for watching and I'll see you in my next episode.