[tslint] lint typescript code #19105
Conversation
spalger
force-pushed
the
implement/typescript
branch
from
d0e0866
to
6811044
Compare
spalger
force-pushed
the
implement/tslint
branch
5 times, most recently
from
96ccc5b
to
8d8b66b
Compare
spalger
added
review
Team:Operations
spalger
requested review from
tylersmalley,
epixa,
weltenwort,
azasypkin and
jbudz
💚 Build Succeeded |
| for (const Linter of [Eslint, Tslint]) { | ||
| const filesToLint = Linter.pickFilesToLint(log, files); | ||
| if (filesToLint.length > 0) { | ||
| await Linter.lintFiles(log, filesToLint); |
There was a problem hiding this comment.
This current implementation doesn't attempt to run tslint at all if there is an error from eslint, so if you have lint failures in both .js and .ts files, you won't know that until you attempt to commit again after fixing the .js files. It should probably run both commands and show the results from each.
There was a problem hiding this comment.
Yeah, the same is true for file casing issues and eslint. If there are casing issues eslint is never run.
I'll put up a separate PR that updates the precommit hook to clearly log errors from multiple tasks and collect those errors into an appropriate exit code, but I personally think it's out of the scope of this PR.
|
I failed to get this to pick up projects located in |
|
@weltenwort just like our current eslint setup this isn't intended to lint things in |
💔 Build Failed |
|
jenkins, test this |
💚 Build Succeeded |
* [tslint] lint typescript code * [tslint] filter projects when running specific project * [dev/ts] use more explicit types * [dev/ts] add note about why using glob * [dev/ts] rely on ts, use fewer getters
|
6.x/6.4: 37487a8 |
Fixes #18780
Adds TSLint integration.
Running
node scripts/tslintwill run the linter on all TypeScript "projects" (defined bytsconfig.jsonfiles). This script is also run as a part of testing anywhere eslint is run.Rules
In order to avoid lengthy debate about which rules to enable we have enabled:
tslint:recommendedpresetno-unused-variablerule (requires type information so it's not a part of the preset)prettierWe can open issues and have discussions about evolving these selections as we go.
Along with the default rules, a custom rule to ensure that license headers are added to files in the
x-packdirectory is in use.To avoid a massive number of changes in this PR
tslint.yamlfiles have been added to the existing TypeScript projects to disable any rules that have violations.Type Checking
TSLint deprecated the ability to type-check while linting, and it's currently providing a different output than we get with the build because it includes files that are not shipped with the build. Rather than block TypeScript integration on this I discussed the options with @azasypkin and we both agree that the type checking done at build time is sufficient as a final check that must pass before files can be committed, that editor integrations are okay for development, and that people can run the
tscdirectly if they want more comprehensive type checking during development: