(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
}
}
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.
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.
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).
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.
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.
@spikyjt Do you mean this feature? https://github.com/palantir/tslint/issues/3744
I also need that :/
Most helpful comment
I don't really agree with this change.
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:
Leaving this issue open for discussion, we can reconsider if there's a lot of community interest in this change.