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

Emit issue with member access dot operator and parentheses usually in conjunction with type assertion #15444

Closed
gdelmas opened this issue Apr 28, 2017 · 9 comments
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug

Comments

@gdelmas
Copy link

gdelmas commented Apr 28, 2017

Code

a.foo()
(b).foo()

Expected emit:

a.foo();
(b).foo();

Actual emit:

a.foo()(b).foo();

This becomes an issue when using type assertions inline:

Code

a.foo()
(b as Bar).foo()

Expected emit:

a.foo();
b.foo();

Actual emit:

a.foo()(b).foo();

Angle brackets type assertion have a similar issue:

Code

a.foo()
<Bar>b.foo()

Actual emit:

a.foo()
    < Bar > b.foo();
@mhegazy
Copy link
Contributor

mhegazy commented Apr 28, 2017

Unfortunately these are the JavaScript Automatic SemiColon Insertion rules.

TypeScript is a super-set of JavaScript, and the samples above are valid JS code samples, and they have valid semantics. the emitted code has to match these semantics.

@mhegazy mhegazy added the Working as Intended The behavior described is the intended behavior; this is not a bug label Apr 28, 2017
@gdelmas
Copy link
Author

gdelmas commented Apr 28, 2017

thanks for your reply @mhegazy. i thought that it is a tricky case, as sometimes a multiline expression might be intended.

i might create a tslint warning to detect it in conjunction with assertions. or might this be a case where tsc can warn itself?

@RyanCavanaugh
Copy link
Member

I believe there's already a TSLint rule for missing semicolons

@gdelmas
Copy link
Author

gdelmas commented Apr 28, 2017

do you mean this tslint core rule:

"semicolon": [true, "never"]

"never" disallows semicolons at the end of every statement except for when they are necessary.

the rule does not warn if a semicolon in conjunction with a type assertion might be required. it also fails in some other cases, and warns. for example:

super(); <-- rule thinks this is unnecessary
(a as Bar).foo()

@RyanCavanaugh
Copy link
Member

Sorry, I totally misread that. Disregard.

@mhegazy perhaps we should disallow boolean as an operand to > / <, even if the other operand is any ?

@ajafff
Copy link
Contributor

ajafff commented Apr 28, 2017

@gdelmas you can use the no-unexpected-multiline provided by tslint-eslint-rules

@mhegazy
Copy link
Contributor

mhegazy commented May 1, 2017

@mhegazy perhaps we should disallow boolean as an operand to > / <, even if the other operand is any

👍

@mhegazy
Copy link
Contributor

mhegazy commented May 1, 2017

Filed #15506 to track it.

@mhegazy
Copy link
Contributor

mhegazy commented May 19, 2017

Automatically closing this issue for housekeeping purposes. The issue labels indicate that it is unactionable at the moment or has already been addressed.

@mhegazy mhegazy closed this as completed May 19, 2017
adidahiya pushed a commit to palantir/tslint that referenced this issue May 24, 2017
…2655)

Separate the implementations of "never" and "always", because "never" became a little more complex.
[enhancement] `semicolon`: option `"never"` is now spec compliant
[bugfix] `semicolon`: don't warn about unnecesary semicolon when it is actually needed, e.g. when followed by type assertion or template string
Ref: microsoft/TypeScript#15444
@microsoft microsoft locked and limited conversation to collaborators Jun 14, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Working as Intended The behavior described is the intended behavior; this is not a bug
Projects
None yet
Development

No branches or pull requests

4 participants