Let's get linting working with Quasar. You're really going to love this. Control-Shift-X to open up my extensions. And if you type in here at recommended, which I've already done, it's going to show you all of the workspace extensions.
In other words, the extensions that Quasar recommends you install for a pleasant experience using Quasar. So I recommend that you go ahead and install all of these, especially Vue Official and ESLint. You might also need to restart VS Code when all of that's done. cjs.
This is how we configure our linting rules. And the first thing I want to do is go straight to the top and remove this line here, View 3 Essential. Basically, this is saying... I want you to use the essential Vue 3 linting rules.
So the rules that Vue says you really should be following these rules to make your code readable when you're using Vue 3. We can also use strongly recommended, but the one that I prefer to use is recommended. This is the strictest linting rules that we can use. So I prefer to start there, and if anything annoys me, then we can scroll down to the rules section.
and we can easily turn rules on and off if they get in the way. And you can see that Quasar has noticed some rules that get in the way with Quasar, and therefore it's turned them off. And we can also see a few rules that it's actually turned on. So in this case, if you break the import slash named rule, you're going to get an error.
And now that all of this is set up, let's go back into our index file, source, pages, index page. and go back to the original formatting. And now look at what happens when we save the file. It automatically formats everything for us.
How cool is that? Super, super handy. And it means that we can write our code a lot faster. In fact, a lot of the time when I'm writing code, I just do everything in one long line, especially inside of the template.
And then it automatically formats for me when I save it. This is a huge productivity boost. You're going to love linting if you haven't tried it before. Now, there are some linting rules that I don't like.
For example, if I have a variable that I'm just kind of playing around with, for example, const unused variable is equal to a blank string. Notice that I get a red squiggly. Now, that's a little bit much for me. When I'm developing, I don't want to get red squigglies and show stopping errors just because I have an unused variable.
So what we can do is we can copy the rule here. So let's go ahead and copy that. No unused vars. cjs.
And then inside of this rules object, I'm just going to add it in here. No unused vars. And let's set that equal to a warning. So by default, it's set to an error, but I'm saying, you know what, warn me.
I want to know that I've got an unused variable, but you don't have to scream at me about it. And the other thing we can do is turn it off entirely if we like. Okay. So let's go back now to our index page.
And now we just get a yellow squiggly. So that's a little bit nicer. We're going to add one more rule because I think you're going to particularly love this one. This rule is going to allow us to automatically order our component tags.
So remember in the previous video, I put the script tag at the top and then the template tag. we can actually enforce that with a linting rule. View slash component dash tags dash order. We'll make that an array.
And at the start of this array, we'll say warn. So throw a warning if this rule is broken. And then let's configure this. For the order, I first want it to be script.
So script at the top. Then I want template. Then I want style tag. So you can set this to any order that you like.
This is the order that we'll use in this series. Now, check this out. Back to the index page, let's grab this script tag and throw it down the bottom. And when we save the file, boom, it switches.
How cool is that? Now, one of the great things about this is you can implement new rules. And if they can automatically be fixed, then we can tell the linter to run it across all of our files. That's what we're going to do right now.
So if we go to the error not found page, notice that a few of these linting rules are broken, especially this one where the script tag is at the bottom. I can come into our console and say yarn lint dash dash fix. So I want to run the linter and as it's running, if it can fix the problems, then go ahead and do that. So let's run that and notice that it's automatically fixed this file for us.
So now the script tag is at the top. So rather than having to go into every single file and save it, we were able to run this one command that fixed it for us. And it's also saying here, ah, I found one error that I couldn't fix. So if I control click that, we can see that it wasn't able to fix this unused variable error.
Now check this out. Let's throw that over onto the side, maybe create a bit more space here and run our server, Quasar Dev. And notice that we get this little window at the bottom, well, not so little, that shows us that we have a linting error. And in order to find that error, we can click on the link, and that takes me directly to where the error is.
In fact, let me show you that. If I close all of these files out and click on that link, it shows you exactly where that linting error occurs. Now, I think showing this window all the time is a little bit overkill. That annoys me a bit whilst developing.
Let's make it so that by default, it's closed. Otherwise, every time we refresh the page, it's going to show up again. Okay. Scrolling down into our Quasar config file, there's a section here where we use the Vite plugin checker.
So to find that, you might want to do Ctrl-F, Vite-plugin-checker. We're just going to add another option here, which is overlay. So, hey, Veet, I want you to tap into this overlay and for initial is open, set that to false. Save it.
Give that a moment. And now we can refresh the page all day long and not get annoyed by that window. But we can see down the bottom here, we've got an error. And when we're ready to fix those errors, we can click in there.
click on where the error occurred, and then fix it up. And I can go, whoops, I've got an unused variable, get rid of it, save the file, and now ESLint isn't complaining anymore. How cool is that? I think this is a wonderful dev experience, and you're going to love having those options available to you throughout this series.
All right, see you in the next video.