Prose formatter to output relative file paths

[reduckted]

Feature request

Is your feature request related to a problem? Please describe.
The prose formatter lists problems with the full path to the file. This causes a lot of redundant text in the output, and makes it harder to read.

Describe the solution you'd like
I would like the prose formatter (and maybe other formatters if appropriate, though I only use the prose formatter) to display relative file paths instead of absolute file paths.

The path could be relative from the current working directory, or perhaps from the directory of the tsconfig.json file (the current working directory feels like the better option).

Describe alternatives you've considered
None.

Additional context
Here's an example of the current output that I see when I run TSLint on a particular repository:

D:\Code\GitHub\tslint-microsoft-contrib>node_modules\.bin\tslint -p tsconfig.json

ERROR: D:/Code/GitHub/tslint-microsoft-contrib/src/chaiPreferContainsToIndexOfRule.ts[32, 41]: variable 'ChaiPreferContainsToIndexOfRuleWalker' used before declaration
ERROR: D:/Code/GitHub/tslint-microsoft-contrib/src/chaiVagueErrorsRule.ts[36, 41]: variable 'ChaiVagueErrorsRuleWalker' used before declaration
ERROR: D:/Code/GitHub/tslint-microsoft-contrib/src/exportNameRule.ts[57, 41]: variable 'ExportNameWalker' used before declaration
ERROR: D:/Code/GitHub/tslint-microsoft-contrib/src/functionNameRule.ts[87, 41]: variable 'FunctionNameRuleWalker' used before declaration

Here is what I would like to see:

D:\Code\GitHub\tslint-microsoft-contrib>node_modules\.bin\tslint -p tsconfig.json

ERROR: src/chaiPreferContainsToIndexOfRule.ts[32, 41]: variable 'ChaiPreferContainsToIndexOfRuleWalker' used before declaration
ERROR: src/chaiVagueErrorsRule.ts[36, 41]: variable 'ChaiVagueErrorsRuleWalker' used before declaration
ERROR: src/exportNameRule.ts[57, 41]: variable 'ExportNameWalker' used before declaration
ERROR: src/functionNameRule.ts[87, 41]: variable 'FunctionNameRuleWalker' used before declaration

[JoshuaKGoldberg]

@reduckted how about stylish being changed to output relative paths? It's been acting something like TypeScript's --pretty, where a guarantee of stable output is replaced with pretty visuals.

We should also figure out what the paths should be relative to. Is it always the root directory being run from? Do monorepos or global installs have different needs?

[reduckted]

how about stylish being changed to output relative paths?

Yep, that sounds like a good idea.

Looking at the type of output from each formatter and whether it's designed to be parsed, here's my thoughts on which ones should use relative paths:

✔️ codeFrame
✔️ prose
✔️ stylish

❌ checkstyle
❌ filesList
❌ json
❌ junit
❌ msbuild
❌ pmd
❌ tap
❌ vso

❔ verbose (it's not really made for parsing, but given its name is "verbose", maybe it should show the full path 🤷‍♂️ ).

We should also figure out what the paths should be relative to. Is it always the root directory being run from?

The current working directory would match what TypeScript's --pretty output shows, and I think it's the most sensible thing to use. Visual Studio Code has the ability to turn file paths in the terminal into clickable links. Relative files paths are treated as relative to the current working directory, so making them relative to any other location would immediately break those links (or have the editor fail to show them as links in the first place). I'm not sure about other editors (Atom, Sublime, etc.), but I assume they would have a similar feature.

Some other options:

Relative to the project file
➕ Would produce stable output, regardless of where you run TSLint from.
➖ Only works when using TSLint with a project file.

Relative to the tslint.json file
➖ Multiple config files can apply to a single source file.

[JoshuaKGoldberg]

❔ verbose (it's not really made for parsing, but given its name is "verbose", maybe it should show the full path 🤷‍♂️ )

#2228 tracks removing prose and #3460 tracks merging prose into verbose. Neither formatter is really made for API consumption given how much better the json formatter is. It should be an acceptable (though still breaking) change to make them use relative paths.

current working directory would match what TypeScript's --pretty output shows

Agreed, maintaining parity with TypeScript seems like best foot forward. It'd be a shame to be surprising to users and have them constantly confuse which tool has which behavior. I know I would!

If file path relativity or root-ness really becomes important, it would be nice to have formatter options. Filed #4281.

Side note: love the use of emojis on that list! Very helpful! 🙌