Option for single space around template string parameters

[Arnavion]

Following #5103, Visual Studio with TS 1.7 prefers to format

`${ foo }`

as

`${foo}`

I (and maybe others?) would like to have single spaces around the parameter expression though. As @mhegazy mentioned there, can there be an option for it in the LS?

/cc @saschanaz

[saschanaz]

Should this be affected by options.InsertSpaceAfterOpeningAndBeforeClosingNonemptyBrackets?

[Arnavion]

No, it should be separate.

[Arnavion]

Also, looking at that change, I see that the previous rule wants to insert a space between a tag function and its template string. That seems really odd as well. I haven't seen any use of template strings on the internet where there's a space between the tag and the string.

[saschanaz]

Ah, I misread the option as braces. So it seems we need a new InsertSpaceAfterOpeningAndBeforeClosingNonemptyBraces option. As for tag function I once thought we need a space between them by some reason but with some searching I think I was wrong.

[saschanaz]

Out of curiousity, do you also prefer let { foo } = {}; import { foo } from "foo" over let {foo} = {}; import {foo} from "foo"? How about let foo = {foo: 3}? Do we need a rule-them-all option for all of them or separate ones?

PS: Just fixed my reversed question, sorry ;)

[Arnavion]

let { foo } = {}; // let { foo } = { }; is also okay
import { foo } from "foo";
let foo = { foo: 3 };

while (true) { }
function foo() { }
() => { }

[Arnavion]

Somewhat related question: Why aren't simply all the rules overridable with ts.FormatCodeOptions in createActiveRules() instead of a hard-coded list of a few options that is then converted into rule values? I can see the benefit that a single option can abstract over multiple rules, but that could be handled by the editor's preferences?

[saschanaz]

👍 for a better rule option system as many (if not all) of the current optional rules are just a "RuleAction.Space or RuleAction.Delete" problem.

[saschanaz]

Going back to the original problem, I personally prefer let foo = { foo: 3 } over let foo = {foo: 3} but prefer ${foo} over ${ foo }, so a completely separate option for template strings may be proper at least before a better system.

[Arnavion]

You could just rename the two rules from that PR from NoSpace... to Space..., and have the new option decide whether they're Delete or Space? Never mind, misunderstood what you meant.

[myitcv]

Can I simply register a 👎 for (further) options in the formatting space. My preference would be the TypeScript core team decide how TypeScript code should be formatted and have the formatter shipped with TypeScript enforce that. That would make TypeScript code easier to write, read, maintain, and remove any debate on which options should be on/off etc (drawing on experiences with gofmt)

[saschanaz]

#6202 to fix this.

[DanielRosenwasser]

@myitcv I think if you tell a bunch of JavaScript developers that to use TypeScript they'll need to use our uncustomizable formatter, they'll tell us where we can put our formatter.

This isn't an option on the table at this point, and removing the formatter from our API would be a breaking change anyway. If TypeScript wasn't based on JavaScript itself, and it wasn't so far after the fact, maybe it would be a different discussion.

[myitcv]

@DanielRosenwasser - nobody is forced to use the formatter. Indeed nobody is prevented from writing another formatter if they are so offended by the core formatter.

removing the formatter from our API would be a breaking change anyway

Just to be clear, I wasn't advocating removing the formatter (far from it, I use it all the time via tsfmt), rather removing the options (or at least putting a freeze on adding any more options).

...they'll tell us where we can put our formatter

I'm sure there are many aspects of TypeScript that would fall into this 'category'. That however is not the point I'm trying to address.

At the moment there are 15 options for the formatter which gives us (conservatively if we consider them all to be binary) a grand total of 32,768 different ways that TypeScript code can be formatted. Does this sound like a desirable situation to be in? When someone is starting a new TypeScript project, what options should they choose? Same goes for compiler options and tslint rules.

This isn't a rant about "I think things should be formatted in way X" rather a dialogue about how to increase TypeScript adoption, make it more accessible, easier to write, read and maintain.

I acknowledge it's a complicated area and that some compiler options are, by virtue of the pre-existing Javascript eco-system, required. So I'm merely flagging that by adding more options (either for formatting, to the compiler etc) we make it more complicated still.

[saschanaz]

When someone is starting a new TypeScript project, what options should they choose?

@myitcv I think they can choose their own preference when there is any, otherwise one can just follow the default values.

[DanielRosenwasser]

Of course. And of course nobody is forced to use the formatter, but that's part of what the language service is offering with our tooling. If it's a matter of "you can use our tooling but you need to turn off the formatter entirely", that's probably a bit of a turn-off. I think the defaults are a good suggestion of how canonical code should be formatted, and anyone who strongly disagrees can tune what they want.

And obviously I'm just one member of the team. If others have a different opinion, I encourage them to tell me I'm wrong. 😄

[Arnavion]

I think the defaults are a good suggestion of how canonical code should be formatted, and anyone who strongly disagrees can tune what they want.

... except the high-priority rules like this one, right?

In fact most of the hi-pri rules are for ES syntax, not TS-specific syntax. Even the ones under // TypeScript-specific rules include ES-syntax-only rules like NoSpaceAfterConstructor.

Some of them like NoSpaceBeforeDot or SpaceAfterVoidOperator seem reasonable, but NoSpaceBeforeOpenParenInFuncCall sounds like it should be overridable. I'm curious about how it was decided which rules go into this list and which are overridable.

[saschanaz]

Even the ones under // TypeScript-specific rules include ES-syntax-only rules like NoSpaceAfterConstructor.

I'm also curious why SpaceAfterCertainTypeScriptKeywords rule contains non-TS-specific tokens when there is SpaceAfterCertainKeywords but maybe because of a historical reason?

[mhegazy]

Thanks @saschanaz for adding the new flag support. now we need to enable this in VS, as well as in Sublime as a user option.