 In a recent video, I talked about some of the challenges developers run into with ESLint rules that Microsoft introduced in the SharePoint framework version 1.15 release. That video covered some of the common rules that you're going to likely run into and how to address some of the warning messages or errors that are going to pop up. But it also showed you how you can selectively disable rules within files or blocks of code or in individual lines or how you can make global changes to a project in the ESLint configuration file in the root of your project. But you have to make these changes in every single project. What if you want to have a single set of ESLint rules for your own coding style that are applied to every SharePoint framework project? Or better yet, what if you need to follow your company's coding style guide? Or what if you're consulted with multiple clients and each one's got their own coding style guides? Making each of these changes in each SharePoint framework project is a pain in its error prone. So wouldn't it be cool if there was a better way? There is. And in this video, I'm going to show you how. Hey, I'm Andrew Coll. This episode is also available as a blog post on boytanos.io and as a podcast on boytanos.show. Check out the description below the video for links to these other resources. Hey, I'm Andrew. And if you're new here, make sure you subscribe to get notified of future videos for professional developers on Microsoft 365 and Microsoft Azure topics. Before I explain and demonstrate my solution, let me first restate an opinion that I expressed in my last video. I don't think a vendor should be defaulting projects with a lot of opinionated coding style rules in them. That's not their place. And it forces individual developers, consultants, or an in-house development team to modify every single project right if they create it, if they've got their own coding style guides. So what I'm going to show you is something that I proposed as a solution to address this challenge. And I'd encourage you to check out the proposal and offer your reaction or comments as Microsoft is monitoring the feedback for possible changes to a future SharePoint framework release. And I've included a link to the discussion item that I created in the description below this video. So if you go to the SP DevDocs repo list and you go to the discussions tab, there's a proposal listed right here. It's item number 8290 and in here I kind of explain kind of my pitch on what we should back off rules and everything, but a little bit farther down is where I get into the proposal that I'm going to run through in this video. And I show like an example of how this could work. Now my proposal is inspired by how the SharePoint framework build toolchain enables developers to modify the webpack configuration that is created on the fly by the build toolchain. So here's how it works. Let's say that the ESLintRC file, that JavaScript file, is changed to look for the presence of another file in a well-known path. And if that file exists, it's going to call an expected method and pass the ESLint, pass in the ESLint configuration for the project. Now the method that it's looking for, the file that it's looking for, that I'm going to create, what that's going to do is it's going to return a new configuration. And if that file didn't exist, then it's going to use the default SharePoint framework configuration. So let me show you how this works. So if I take an existing project that I have here, I've got a couple things in this project that I know we're going to cause some issues with the default linting rules that we have listed in a SharePoint framework project. So if I come over here to my console and I just do a gulp build on my project, so what you see here is I've got two errors that are showing up. And both of them are related to a linting error called no async and await. And effectively, what these are doing, if I come over here and look at my actual web part in this project, what you're going to see here is I put the async keyword on two methods, one here on line 40 and one here on line 45. The one on line 45 is the method that I wrote, but then I also changed the on a knit method we get in the out-of-the-box SharePoint framework web parts that it returns a promise. And I just said I wanted to use the async keyword in there as well, the await keyword. So I added the async keyword to the declaration or the method declaration. So what I want to do is I want to get rid of these warning messages in all of my SharePoint framework projects. So how can I go about doing this? So let me show you how this works. So just to review, if I come back over here and look at a default project, you'll see this eslintrc.js file. And that's the default thing we get in a SharePoint framework project, or at least in a version 1.15 project. And you can see here there's really nothing special with this. All of the rules are being defined in these different profiles that Microsoft is already adding to the project throughout a whole bunch of dependencies that have got set up. So the rules are not being set here, but they're being set deep within the node modules folder. And that's where we're getting this async and await. Now, one thing I do want to say before we kind of dive into this is that what I'm going to show you is something that I've proposed to Microsoft to change the eslintrc.js file. And I did that in this discussion item that I mentioned earlier. I'm going to go through these changes in just a second. Now, unfortunately, it looks like Microsoft is not going to go with what I'm suggesting here or what I'm requesting, but that's where your feedback can actually play a role. So if you want to have an impact on this, this is your chance to do that. But regardless, even if they don't apply this, this is something that you can apply to all of your projects if you wanted to. So let's see how to do this. So the way that this is going to work is that if I go to the eslint JavaScript file, what I want to do is I want to take the default configuration that Microsoft is going to use or that Microsoft is creating. And I want to look to see if another file exists with a very specific name. And if that file exists, what I want to do is I want to go take the configuration that they're creating. I want to hand it to my custom file that's on my machine where I can go through and manipulate the configuration and then hand it back to this file, the eslintrc file that's in the root of our project. And that way I have a chance to go through and to make a change to it before it gets deployed. So let me show you the change I'm going to make here. So I'm going to do one little change real quick and I'm going to set the default for the configuration that they're creating. I'm going to go ahead and modify that. And I'm going to say const default eslint config. We'll just do this with a lowercase l is one. Okay, so that's the default configuration that Microsoft is going to have. So what I want to do is I want to check to see if another file exists on my machine. So let's do a const FS require. We're going to need the FS module. We're going to need the path module and we're also going to need the OS module as well. So here's what I'm going to do. I'm going to have a user eslint config file. So that's going to be what my configuration file is. And let's see if this thing, let's go through and get a reference to where this file lives. So I'm going to expect to have that file live in a very specific location. I'm going to look in the home directory for the current user. So that's the root of my profile. And I'm going to look for a file name.spfxeslintrc.js. Okay, so that's the JavaScript file that I'm looking for. So what I want to do is I want to check to see, let's go through and let's return back a configuration back to this configuration file. So what I'm going to do is the same way how Microsoft had their setup where they were simply doing a module.exports at the online too. I'm going to say module.exports and we're going to export a configuration. But I want to first check to see if there is a file that we just had right here, the user eslint config. If my file on my machine exists, what I'm going to do is I'm going to say, I'm going to load in, go to require of the user eslint configuration. And I'm going to expect that this file has a method named merge eslint config defined on it. And I'm going to pass in the Microsoft default configuration. So I'm going to have to write that method. If the file exists, it expects that one method to be exposed or be exported from the module. And it's going to take in the configuration and return a configuration back, which is what's going to be exported back to eslint as it works like out of the box. If that's not the case though, then well, I just want to go ahead and use the default configuration so that this way, so this file doesn't exist on my machine. So now when I run a gulp build again, everything should still look the exact same way because my project is not finding that file or that eslint configuration is not going to find that file as I was going to continue to use the out of the box eslint configuration that the SharePoint framework provides. And we can see that right here. Okay, as I said, I don't really agree with these warning messages because that async keyword is perfectly fine to use as it never touches the browser. It says here that it's got an overhead with you being using older browsers. We're compiling TypeScript to JavaScript. And so that, and when it does that, the async keyword is not going to be in the JavaScript that's being generated because we're generating ES5, ECMAScript 5, which is from 2009. So the async keyword is never going to be seen by the browser. So as far as I'm concerned, this rule is irrelevant. And then there could be other rules that I want to override as well, but we're just going to do this one for right now. So let's say that I want to override this rule that comes with every single SharePoint framework project and I want to turn this warning off. So what I'm going to do is I'm going to create a new file in the root of my home profile. So I'm going to use this file right here. So we'll take that file from our home directory and I'm going to go say touch right into the root. We're just going to add that file in. There we go. And now let's go ahead and let's open that file in VS code. There we go. So here's that file that we want. Now what I want to do here is I need to go through and set and create a function that's going to be exported that we're expecting it to be a specific name or merge ESLint config. So I'll do that. And I'll say exports.merge, just do it like that. Make sure I'll mess anything up. And that's going to accept in an ESLint config and we're going to pass that into this function. So let's now go in and let's change the rule. Let's modify this configuration object. So I'm going to say ESLint config. There's a rules property on the configuration that's defined in the ESLint schema and the ESLint configuration object. And what I'm going to do is I'm going to pass in name value pairs. So in this case, I'm going to have the name of this rule that I want to not have run. Let's paste that in. And if I look at the docs, I can see there's a bunch of different options for this. But one of them is just to say off, which is just to turn this rule off. I don't want it to be applied. So if this file exists, when I build my project, it should find this file. The ESLint should, when it goes to load the configuration, it's going to find this file, pass in the configuration. I'm then going to go modify the configuration by adding in a rules property and adding in this rule to override it and say to turn that rule off. And then I'm simply going to return back the configuration that we've just modified. So that way we're getting that on the fly kind of configuration. So now when I come over here and I build my project, so notice that by adding this well-known file, the SharePoint framework projects are now going to call my JavaScript file, which has a chance to modify the ESLint configuration before ESLint is run on my project. And now I can have a global configuration on my Dev environment. I could even take this further by having my JavaScript file figure out which set of rules I should be using and dynamically load them. Maybe using differently named rules for different clients or dynamically pulling rules from a central location for my company coding standard. The point is now we're in control of our own rules. Now there is one caveat to this approach that it allows a developer to change the linting process on their workstation, but not in the project that multiple developers may share. You can think that if my set of rules on my laptop are different than yours and we're both working on this project, you may get warnings that I don't get or vice versa. Well, that's true. I think that the flexibility of this solution though is best for developers, but just to address that one concern, if the linting rules and the project's default configuration stay with the project, so they stay in this ESLint rc.js file, then they're always going to be applied when the project goes through the continuous integration process when these projects are all committed to their repos and when builds run. So I'm curious, what do you think about this? Do you like the rules that Microsoft gives us in a new SharePoint framework project or do you like having it baked into default projects where we can override the ESLint configuration like I've shown here? Let me know by dropping a comment below and let me know if you wanna see more videos about the SharePoint framework. And if you liked this video, please give me a thumbs up and subscribe by smashing that big red subscribe button below the video. So you're gonna see when I publish more videos for professional developers on Microsoft 365, Microsoft Azure, and including topics on SharePoint framework.