Linters have been around for ages - it all started back in 1978 apparently - but has now become a mainstay of modern JavaScript and TypeScript programming.
Writing code without a linter is like writing an essay without using spell checker! Sure there may be some super humans who can write their code perfectly without linting - but I’m not one of those!
- Enforcing semantic code rules such as not using
var
in TypeScript or using let
when it could be const
because the value doesn’t change. These rules are designed to help you trap bugs as early as possible and enforce best practices.
- Formatting rules - such as not mixing tabs and spaces and adding spaces before and after keywords.
For TypeScript, we can enforce rules using eslint - and automatically format our code using prettier.
There are a whole raft of style rules that then can be applied for different libraries such as react.
This post shows you how to setup linting quickly and easily for a TypeScript PCF project that uses React.
Create your PCF project
Create your pcf project using your CLI/IDE of choice:
I use:
pac pcf init --namespace dev1 --name pcflint --template field
npm install react react-dom @fluentui/react
Install ESLint, Prettier and the plugins
Prettier is great for formatting your code, but doesn’t really do any of the semantic code checks. So the configuration we are going to create uses prettier as a plugin from within eslint
. This means when you run eslint
, no only will it warn and attempt to fix semantic issues, it’ll also tidy up the formatting for you using prettier.
npm install eslint --save-dev
You can use the bootstrapper if you want - but this can lead to a configuration that you don’t really want:
npm install --save-dev --save-exact prettier
We use the --save-exact as recommended by the project because sometimes formatting rules can change slightly and you don’t suddenly want your source control diffs to include formatting differences.
- Now install the plugins and configurations needed for our rules:
npm install --save-dev @typescript-eslint/eslint-plugin @typescript-eslint/parser eslint-plugin-react eslint-config-prettier eslint-plugin-prettier
{
"parser": "@typescript-eslint/parser",
"env": {
"browser": true,
"commonjs": true,
"es6": true,
"jest": true,
"jasmine": true
},
"extends": [
"plugin:@typescript-eslint/recommended",
"plugin:prettier/recommended",
"plugin:react/recommended",
"prettier",
"prettier/@typescript-eslint",
"prettier/react"
],
"parserOptions": {
"project": "./tsconfig.json"
},
"settings": {
"react": {
"pragma": "React",
"version": "detect"
}
},
"plugins": [
"@typescript-eslint",
"prettier"
],
"rules": {
"prettier/prettier": "error"
},
"overrides": [
{
"files": ["*.ts"],
"rules": {
"camelcase": [2, { "properties": "never" }]
}
}
]
}
- There is an override rule to allow non-camelcase property names since we often use pascal named SchemaNames from CDS.
- There is support for jest and jasmine tests.
Now configure the prettier rules by creating a file called .prettierrc.json
{
"semi": true,
"trailingComma": "all",
"singleQuote": false,
"printWidth": 120,
"tabWidth": 2,
"endOfLine":"auto"
}
Let the magic happen!
There are two ways to get eslint
to do its job:
- Run from the command line
- Use a VSCode extension.
Note: Both approaches will require you to have setup eslint
and prettier already
Run from the command line:
- You will need to globally install
eslint
:
- After that you can add a script to your package.config:
"scripts": {
...
"lint": "eslint ./**/*.ts --fix"
},
Run from inside VSCode
This is my day-to-day use of eslint.
I really recommend getting linting into your workflow early on – because you don’t want to enable it later and then find you have 1000’s of issues to wade through!
@ScottDurow