Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

unnecessary semi insertion for typescript type cast #2693

Closed
e-cloud opened this issue Aug 29, 2017 · 3 comments
Closed

unnecessary semi insertion for typescript type cast #2693

e-cloud opened this issue Aug 29, 2017 · 3 comments
Labels
locked-due-to-inactivity Please open a new issue and fill out the template instead of commenting.

Comments

@e-cloud
Copy link

e-cloud commented Aug 29, 2017

Example:
source:

class A {
    handleInputFocus(): void {
        (<HTMLInputElement>this._input.nativeElement).select()
    }
}

expected output:
the same as source.

actual output:

class A {
    handleInputFocus(): void {
        ;(<HTMLInputElement>this._input.nativeElement).select()
    }
}

a semicolon is inserted before the left parentheses, which should not be.

@e-cloud e-cloud changed the title unnecessary semi insertion for typescript type case unnecessary semi insertion for typescript type cast Aug 29, 2017
@lydell
Copy link
Member

lydell commented Aug 29, 2017

This is actually intended. As described in the options:

Semicolons - Print semicolons at the ends of statements.

Valid options:

  • true - add a semicolon at the end of every statement
  • false - only add semicolons at the beginning of lines that may introduce ASI failures

See #1935 and the issues it links to.

@lydell lydell closed this as completed Aug 29, 2017
@e-cloud
Copy link
Author

e-cloud commented Aug 29, 2017

I use tslint check the code for typescript files.

However, I notice that, after i use prettier to format ts files, all that warning tslint is complaining about are some code like:

{
     ;(<SomeType>varibale).somemethod()
     //...
}

Since the semi-inserted statement is the first statement within a code block, there is no way it would raise ASI failures. Am i right?

@lydell
Copy link
Member

lydell commented Aug 29, 2017

#736 (comment)

@lock lock bot added the locked-due-to-inactivity Please open a new issue and fill out the template instead of commenting. label Jul 6, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Jul 6, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked-due-to-inactivity Please open a new issue and fill out the template instead of commenting.
Projects
None yet
Development

No branches or pull requests

2 participants