tsvet vs tsetse

[myitcv]

Starting a thread here to pick up from (and track) the email conversation we're otherwise having about tsvet:

https://docs.google.com/document/d/1ax2qdMxBdOYvMI9R5E56nT8Tn8idoSop1UAS1jTzXYk/edit

[myitcv]

From @JKillian on 28 Apr 2016:

I wasn't able to comment on the document (maybe you have to explicitly allow that Paul?), so I've left a few initial thoughts below:

I wanted to think at a high level about the ideal workflow for a developer writing a TS application. To me it would look something similar to such:

1) format TS code with an automatic formatter (not thinking about formatting means more thinking about semantics, which is a big positive) 2) compile TS code with tsc and project settings in tsconfig.json (Alex, you said you often wrap the compiler API, not sure the implications of this) 3) analyze code (either as part of the tsc run via extensions, or as a third-party tool)

All these tools would use a source-of-truth tsconfig.json file to determine what files to operate on. (Although I have seen a comment or two against this.) Ideally for me, all these tools would have sane default settings for out of the box use, but they'd also allow full customization. To me, it's important to have conformity across a project, but worldwide conformity isn't as important. One company might have different formatting preferences than another.

I think all this overall aligns closely with the overall goals in the proposal, although I lean a slightly different way on customization it seems.

An open question from my end is if the TS formatter is reliable, flexible, and thorough enough to be this tool. If any of these three things aren't true, getting rid of formatting checks from a tool like tslint or tsvet.

Given the previous point, how do we handle the fact that people now need to: First learn TypeScript; Then learn what tsvet allows, effectively unlearning bits of TypeScript

I'm not so certain on the meaning of is question. What sort of rules would tsvet employ that would involve unlearning TS? The currently proposed rules don't seem too difficult, although they might cause people to change some habits. I have a few comments about the individual rules but I'll leave those as comments on the document when I can. I'm also curious what bigger scope, "dream" tsvet rules would look like. What would be the best-case kind of analysis that tsvet could provide?

[myitcv]

CC @alexeagle @vvakame @JoshuaKGoldberg @adidahiya @JKillian to move the conversation here.

@JKillian

To me, it's important to have conformity across a project, but worldwide conformity isn't as important. One company might have different formatting preferences than another.

This is where we disagree. My goal is to make TypeScript as easy as possible to:

• write
• read
• maintain

Any differences in the way code is formatted, let alone differences in styles as far as variable naming etc are concerned, detract from the points above.

Particularly given the extent to which projects these days rely on external dependencies (and therefore likely contribute back to them). It should be seamless to move between one project and the next.

Having an option space for formatting, style, vet etc only contributes to making this goal less achievable.

An open question from my end is if the TS formatter is reliable, flexible, and thorough enough to be this tool. If any of these three things aren't true, getting rid of formatting checks from a tool like tslint or tsvet.

If it (tsfmt) is not reliable enough then changes need to be made to TypeScript core. The solution is not to come up with a solution via tslint that requires people to make changes manually. Fix things once centrally and in an automated way, and hence avoid the n thousand developers having to make the changes manually by hand every time.

Again, we disagree on the point about it being flexible - this is not a requirement to my mind.

Given the previous point, how do we handle the fact that people now need to: First learn TypeScript; Then learn what tsvet allows, effectively unlearning bits of TypeScript

I'm not so certain on the meaning of is question.

The particular rule I have in mind regards the + operator, specifically Rule 3 in the proposal. In the Javascript world it is permissible to do the following:

let x = 5 + "4";

This would not be allowed by tsvet because of the cognitive load associated with understanding what the resulting type will be. The very fact a matrix of possible combinations and resulting types is required to explain this operator is too much to my mind; there are a number of cases where people contributing to tslint (let alone other projects) have mistakenly understood the resulting type of this operator.

Incidentally, this is not a case of being a beginner vs being an expert. All TypeScript code should be equally understandable, regardless of experience.

Hence the "unlearning" bit here would be that anyone reading the above spec link would then have to unlearn what they know about the + operator, and realise that it is only permissible where the LHS and RHS types are identical (and even then we probably want to ensure that people start with strictNullChecks)

[JoshuaKGoldberg]

One company might have different formatting preferences than another

@myitcv For that reason alone I don't think it's practical for tsvet or tsetse to take an opinionated standpoint on what's "correct" TypeScript. We may all agree on the "perfect" TypeScript style such as near-mistakes like 5 + "4", but we're the special few.

Also, consider a 100k+ line existing JavaScript codebase that is about to be converted to TypeScript. The typical workflow will be:

1. Clean up the JavaScript as much as possible
2. Rename .js files to .ts and fix the immediate compiler errors (often with any casts)
3. Slowly convert parts of the codebase
   • Add interfaces
   • Refactor into classes
   • Other TypeScript-y wonders
   • Add tslint (hopefully)

Any attempt to force the "perfect" TypeScript configuration would be difficult to implement and cause a large number of bugs. This is true for both tslint and tsvet/tsetse. Instead, tools like these are incrementally turned on a few rules at a time to minimize disruption.

The tslint approach seems to be perfect: have a sane set of defaults, with recommended initial configuration, and allow .json configs to opt-in and opt-out as needed.

[myitcv]

@JoshuaKGoldberg

One company might have different formatting preferences than another

@myitcv For that reason alone I don't think it's practical for tsvet or tsetse to take an opinionated standpoint on what's "correct" TypeScript. We may all agree on the "perfect" TypeScript style such as near-mistakes like 5 + "4", but we're the special few.

I don't think it's right to consider "we're the special few." The goal here is to make writing (reading and maintaining) correct TypeScript as easy as possible for everyone, regardless of experience. If it's a common mistake to expect 5 + "4" to give result X, why not prevent it in the first place? (Arguably in this situation you would correct the the TypeScript spec but I suspect that ship has sailed)

Also, consider a 100k+ line existing JavaScript codebase that is about to be converted to TypeScript

The tooling required to convert a Javascript codebase to a TypeScript codebase is a separate matter. I'm not trying to skirt around the problem you describe, but it is orthogonal.

This is true for both tslint and tsvet/tsetse. Instead, tools like these are incrementally turned on a few rules at a time to minimize disruption.

I agree you need some sort of incremental approach to "fixing" a codebase.

With tsfmt it is a no-brainer. No configuration required, it just "works."

For tsvet (ignoring other tools for a second), all I'm proposing is that a developer be required to turn off a rule, rather than turn it on.

Just to repeat, there is no obligation to use tsfmt, tslint, tsetse, tsvet etc. If developers really want to format code by hand, then they can ignore tsfmt. If developers really want to fall into common traps then they can avoid tsvet. If developers don't want to conform to a common coding style they can ignore tslint.