Custom formatters are not used if they have the same name as built in formatters

[spikyjt]

Bug Report

• TSLint version: 5.11.0
• TypeScript version: 3.2.1
• Running TSLint via: CLI

TypeScript code being linted

(N/A)

// code snippet

with tslint.json configuration:

{
  "defaultSeverity": "warning",
  "extends": [
    "tslint:recommended",
    "tslint-eslint-rules"
  ],
  "linterOptions": {
    "exclude": [
      "node_modules/**"
    ]
  },
  "rules": {
    "one-line": false,
    "brace-style": [ true, "allman", { "allowSingleLine": false } ],
    "quotemark": [ true, "single" ],
    "space-before-function-paren": [ true, "always" ],
    "no-unused-expression": [ true, "allow-new" ],
    "object-literal-shorthand": [ true, "never" ],
    "ter-func-call-spacing": [ true, "never" ],
    "ter-padded-blocks": [ true, { "classes": "always" } ],
    "no-console": false
  }
}

Actual behavior

Even with formatters-dir specified on the CLI, the built in formatters are used with preference to custom ones. This means plugins such as tslint-junit-formatter cannot be used.

Expected behavior

Customer formatter should be used even if it has the same name as a built in one, because the formatters-dir has been specified explicitly.

[spikyjt]

Just to clarify I used the following command:

tslint --project ./tsconfig.json --formatters-dir ./node_modules/tslint-junit-formatter/formatters --format junit

In case someone says "who cares? there is already a built in junit formatter, why do you need another?" this module has a feature I need that the built in one doesn't (which I will also submit here as a feature request).

[JoshuaKGoldberg]

Seems reasonable, thanks for pointing this out @spikyjt! Although it's a breaking change, it's one users have to opt into and can easily remove, so it seems fine to accept PRs for now.

[adidahiya]

I don't really agree with this change.

Customer formatter should be used even if it has the same name as a built in one, because the formatters-dir has been specified explicitly.

This formatters-dir is a place to look for additional formatters. If this change were made, I could argue that it is confusing for a developer to come across a project using a formatter called "junit" which is not the built-in one, when all other TS projects they have seen up to that point using the "junit" formatter utilized the built-in one.

Lastly, we should be consistent in how we make this change for custom rules & custom formatters. Currently, the documentation states:

Core rules cannot be overwritten with a custom implementation.

Leaving this issue open for discussion, we can reconsider if there's a lot of community interest in this change.

[LekoArts]

@spikyjt Do you mean this feature? #3744
I also need that :/