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.
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.
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! :)
thank you for the info and examples!