Always be linting your TypeScript!

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!

Much has been written about linting since 1978 and there are plenty of opinions! For me there are two parts:

  1. 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.
  2. 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
yo pcf --force

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:

npx eslint --init
  1. Next up is installing prettier (;
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.

  1. 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
  1. Next we configure setline to call prettier when it is run ( - this uses estlint-plugin-prettier
    Create a file named .eslintrc.json:
    "env": {
        "browser": true,
        "commonjs": true,
        "es6": true,
        "jest": true,
        "jasmine": true
    "extends": [
    "parserOptions": {
        "project": "./tsconfig.json"
    "settings": {
        "react": {
          "pragma": "React",
          "version": "detect"
    "plugins": [
    "rules": {
        "prettier/prettier": "error"
    "overrides": [
          "files": ["*.ts"],
          "rules": {
            "camelcase": [2, { "properties": "never" }]


  1. There is an override rule to allow non-camelcase property names since we often use pascal named SchemaNames from CDS.
  2. 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,

Let the magic happen!

There are two ways to get eslint to do its job:

  1. Run from the command line
  2. Use a VSCode extension.

Note: Both approaches will require you to have setup eslint and prettier already

Run from the command line:

  1. You will need to globally install eslint:
npm install -g eslint
  1. 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.

  1. Install the eslint VSCode extension -
  2. lint issues will show up via a code-lens - the details show up using Ctrl-.
  3. You can auto-format your code using Alt-SHIFT-P

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!


Comments (1) -

  • Great article! It is critical to look after the source code in every project, I can't imagine pushing any code to production without lint checks.

    Do you have any quick tips and tricks for installing/configuring linter(s) in an existing codebase?
Comments are closed