Typescript: No formatter option for space between colon and type in TypeScript

Created on 18 Nov 2016  路  15Comments  路  Source: microsoft/TypeScript

_From @M-Pixel on October 20, 2016 5:42_

  • VSCode Version: 1.6.1
  • OS Version: Win 10

Steps to Reproduce:

  1. Write a TypeScript interface definition omitting space between colon and type (e.g. name:string)
  2. Autoformat
  3. Note that a space was inserted between ":" and "string"
  4. Open user preferences in order to change this behavior
  5. Note that among the many typescript.format.insertSpaceAfter* options, none address this area of syntax.

I prefer to omit this conventional space in order to differentiate {key: val} from {name:Type}. It would be nice to have the option to autoformat without having to forgo this convention.

_Copied from original issue: Microsoft/vscode#14041_

Awaiting More Feedback Declined Formatter Suggestion VS Code Tracked

Most helpful comment

Our team has adapted the convention of no space between the colon and type in TypeScript, but VSCode does not support this. This currently prevents me from utilizing auto-formatting in VSCode. Eagerly waiting for VSCode team to implement this format option. Thank you!

All 15 comments

_From @kcbleeker on October 20, 2016 9:48_

Yes please

_From @roblourens on October 20, 2016 17:54_

I think we only get the formatting options that the TS service exposes.

_From @kcbleeker on October 20, 2016 18:20_

That's a little frustrating in a VSCode versus IntelliJ battle.

_From @roblourens on October 20, 2016 18:22_

tslint autofix might do this.

@M-Pixel thank you for opening this issue. We are looking at ways to improve this experience and will consider your specific use case. Are there are formatting options you would like to see?

Ping @jrieken as this might be relevant for your formatting work.

Please also consider my code formatting suggestions. https://github.com/Microsoft/TypeScript/issues/9124

@heroboy noted on my end. thank you.

@waderyan For reference on @roblourens idea about tslint autofix, it doesn't look like it can autofix this at this stage, and I feel that running a formatOnSave which "breaks" the formatting, and then trying to undo that with lint autofix is the wrong way to operate anyway.

Our team has adapted the convention of no space between the colon and type in TypeScript, but VSCode does not support this. This currently prevents me from utilizing auto-formatting in VSCode. Eagerly waiting for VSCode team to implement this format option. Thank you!

Any updates on this?

+1 - we also need that feature. tslint has the option but it doesn't work correctly when both format and tslint fix are applied on save.

Since the colon : already divides the variable name from its type annotation, I see no reason for the additional empty space separator, so I also would like this to be a user-preference. Shouldn't be too difficult to implement for somebody familiar with the code. Thank you.

It's been 4 years and still no option for this?

I don't see any harm in having more customisation options for formatting.
Especially since there's already a matching option insertSpaceBeforeTypeAnnotation, which arguably is a rarer use case.

Consider:

function foo(e: (a: number, b: string | { f: string, g: boolean }) => void, o?: boolean): { r: string, d: any} { ... }

and:

function foo(e:(a:number, b:string | { f:string, g:boolean }) => void, o?:boolean):{ r:string, d:any } { ... }

The space after colon can feel unnecessary and feel like forcing the lines to be longer than they need to be.

Also, I can read the types of each parameter/field much more easily without the space after colon, since they are more "grouped" together with the names.
Spaces after colons make them look like they're values, instead of types.

From discussion on the team:

After 4 years and only 18 upvotes, we haven't received enough feedback to really justify the work and extra editor flags here, nor do we believe it's a good stylistic choice for code.

My take on this is that flags add complexity. Features that we think are not useful aren't worth the complexity of a new flag.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

weswigham picture weswigham  路  3Comments

wmaurer picture wmaurer  路  3Comments

seanzer picture seanzer  路  3Comments

Antony-Jones picture Antony-Jones  路  3Comments

dlaberge picture dlaberge  路  3Comments