build: add tslint formatting task

[crisbeto]

Adds a Gulp task that fixes TSLint errors automatically when possible. This should make it easier to add/remove linting rules.

[devversion]

I don't really think that it is necessary to have such a task. It happens to rarely that we add/remove tslint rules.

Most of the time those rules can be fixed manually very quickly and if really necessary we can just run $(npm bin)/tslint **/*.ts --fix.

[crisbeto]

I think it's fine, because:

1. It's a simple one-liner.
2. It's a lot easier to remember.
3. It can still save us a lot of manual work.

[devversion]

Hm I personally not agree with that.

1. It doesn't really matter. It's about unnecessary stuff inside of our already big build process.
2. That probably depends. tslint **/*.ts --fix feels more convenient to me (also is more flexible)
3. As said we don't change rules very often and if we have to (rarely) then we can just run the command.

Decision might be up to @jelbourn. I just want to make sure that we don't add stuff to the build process that will be likely used once in a year. It should be as tight & clean as possible.

[crisbeto]

FWIW, it's not only down to tslint **/*.ts --fix, you also need to pass it the path to a tsconfig.json.

[devversion]

@crisbeto The tsconfig file needs to passed if the project uses rules that require TypeScript's TypeChecker from the program.

[crisbeto]

My guess is that will be the case once we disable the custom rule for unused imports, which throws an error atm, and we start using tslint's built-in rule.

[devversion]

Yeah but that is a separate issue to fix the getHighlights error from the language service. And yeah this rule would require the type checker.

[jelbourn]

I'm all for auto-fix, and we should probably just make it a pre-commit hook for everyone (probably without gulp there).

@crisbeto what is the set of things it will fix? Presumably obvious things like missing semi-colon and using the wrong quotes, but I'd guess line-breaking would be out of scope.

[crisbeto]

I believe that it depends on whether the particular rule has a corresponding "fixer". Not sure if there's a good way to see which ones do, though. These are the built-in ones that do.

[jelbourn]

LGTM

[jelbourn]

@crisbeto just needs rebase

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}