Not bad… but it would be way cooler to see the feedback directly inside our IDE without having to worry about running that command in our terminal.
#Airbnb js formatter code#
Now this is really cool! We can catch common mistakes and errors in our code by running a single command and fix them before they go into production - hoozah! ☄🧙♂️ If you change it to plugin:vue/recommended you’ll get close to 80% of the rules available. The essential extension is the loosest of them all.
#Airbnb js formatter full#
You can see a full list of rules and extend options here: That’s where the no-template-key rule is coming from. You should see a section called extends and the first item in the array will be plugin:vue/essential. This is set inside the package.json file under eslintConfig. If you remove the key and run yarn lint again you’ll see a clean run! This happens because one of the default rules configured from the CLI is no-template-key, an example of a code quality rule. Place the key on real elements instead (vue/no-template-key) at src/components/Hello.vue:1:1: If you run the command npm run lint or yarn lint you should see an error with the text: error: '' cannot be keyed. Just incase at the time of reading there are newer versions of the CLI scaffold your project like this:
#Airbnb js formatter how to#
If you’d like to see a more in-depth tutorial explaining how to set this all up from scratch, let me know in the comments below! This will get us 90% of the way to having everything we need so it makes sense to just do this. 🔧 Initial Set Upįor this tutorial we’re going to use the Vue CLI to scaffold our VueJS project.
This means we need to set them both up to handle what they’re strongest at. None-the-less it’s important to categorize the two as separate concerns, since the tools we’re going to be configuring need to play together nicely. This line drawn between code style and code quality can also be blurry since arguably having consistent style is a part of having good code quality. ESLint, for example, has plenty of rules that are just code style related. Linters usually have some overlap with formatters. Like whether you should include a semi-colon at the end of a statement (the answer is NO obviously 🙄), or if indentations should be 2 spaces or 4. Linting rules are designed to catch common gotchas or code smells 🦨 and are intended to help developers prevent them from happening in their code bases 🏰.įormatters on the other hand, are concerned with code style. Having a rule setup that disallows empty functions is an example of a check for code quality. Linters are primarily concerned with code quality. for ESLint to use.Īll of these options give you fine-grained control over how ESLint treats your code.First, it’s important we understand the difference between linting and formatting.
0 kommentar(er)
