Skip to content
This repository has been archived by the owner on Mar 25, 2021. It is now read-only.

print nothing when no failures #1553

Merged
merged 2 commits into from
Sep 19, 2016
Merged

print nothing when no failures #1553

merged 2 commits into from
Sep 19, 2016

Conversation

alexeagle
Copy link
Contributor

8fd8723 introduced a change
where the proseFormatter writes a single newline to stdout when there are no failures

@palantirtech
Copy link
Member

Thanks for your interest in palantir/tslint, @alexeagle! Before we can accept your pull request, you need to sign our contributor license agreement - just visit https://cla.palantir.com/ and follow the instructions. Once you sign, I'll automatically update this pull request.

palantir@8fd8723 introduced a change
where the proseFormatter writes a single newline to stdout when there are no failures
@jkillian
Copy link
Contributor

Wanted to note that there's been some discussion on this before: #1463 (comment)

@caugner was of the opinion that a newline should be written when there are no failures

@@ -20,6 +20,10 @@ import {RuleFailure} from "../language/rule/rule";

export class Formatter extends AbstractFormatter {
public format(failures: RuleFailure[]): string {
if (!failures.length) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TSLint norms is to do an explicit comparison, (failures.length === 0).

Just curious, do you have that feature enabled that lets TSLint maintainers make modifications to your PR branch? I haven't gotten a chance to try it out yet, and something like this is the ideal scenario

@jkillian
Copy link
Contributor

However, I'm leaning towards agreeing with you @alexeagle. Obviously, some formatters will always have output - for example, a JSON formatter would always output {}. However, it doesn't make sense for a formatter, like prose to emit a blank line. Similarly, a program like grep doesn't print a blank line when there are no results found.

@alexeagle
Copy link
Contributor Author

The reason I found this is that we have some internal tests for our tslint integration. We assert on the exit code by sensing whether there is any output, this way we don't need some other golden file saying what the exit code should be.
I could trim() that (in bash) before that logic, but I figured that non-empty output in the success case was probably an accident.

@alexeagle
Copy link
Contributor Author

Allow edits from maintainers. is checked - so give that a try?

@jkillian
Copy link
Contributor

Hmm, can't get it working for some reason. I'm going to try again tomorrow, but if I can't figure it out I'll merge this, no need for any changes on your end

@jkillian jkillian merged commit 131a8f8 into palantir:master Sep 19, 2016
adidahiya pushed a commit that referenced this pull request Sep 21, 2016
Addresses review #875140 in PR #1558 for compatibility with discussion item #1553
alexeagle pushed a commit to alexeagle/tslint that referenced this pull request Sep 23, 2016
)

Addresses review #875140 in PR palantir#1558 for compatibility with discussion item palantir#1553
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants