DEV Community

Discussion on: Linting an Existing Application: 3 Key Things I Learned

Collapse
mroeling profile image
Mark Roeling

Having a ts code base ourselves, and officially there is no official coding standard, we looked at Prettier.io.
It turned out that recently (?) the separate rules can be edited. Also, tslint is deprecated, and eslint is the way to go.

These things combined made us go for eslint, with the addition of some plugins.

    parser: '@typescript-eslint/parser',  // Specifies the ESLint parser
    extends: [
        'plugin:@typescript-eslint/recommended',  // Uses the recommended rules from the @typescript-eslint/eslint-plugin
        'prettier/@typescript-eslint',  // Uses eslint-config-prettier to disable ESLint rules from @typescript-eslint/eslint-plugin that would conflict with prettier
        // 'plugin:prettier/recommended',  // Enables eslint-plugin-prettier and displays prettier errors as ESLint errors. Make sure this is always the last configuration in the extends array.
    ]

The recommended Prettier settings we disabled, since that colided with some of the settings we wanted to set. In the rules section we added some 20 more settings.

The result is a codebase that now is linted on every (Jenkins) build, failing on every warning or error. 100% eslint, 100% phpcs, 100% phpunit coverage, and starting with Cypress for the e2e testing.

Extra +1 for the playlist! :)

Collapse
scarlettperry profile image
scarlett Author

thank you for the info and examples!