Breaking: Include type annotation range for Identifiers (fixes #314)

[soda0289]

I changed range of Identifier nodes used in variable declaration and function parameters. Its a simple change but I might have missed something.

[eslintbot]

LGTM

[JamesHenry]

I got chance to dig into this today, and we still have a fundamental difference in how we conclude ranges for typeAnnotations vs how Flow does it for the same source.

Take this example:

let x   :      string;

Flow has the following ranges:

Whereas in this PR we currently have:

I have a fix for this when it comes to VariableDeclarations (building on this PR) so I'll just push it up for your review @soda0289.

We'll likely be able to turn it into a utility function and apply it to other constructs with typeAnnotations as well

[eslintbot]

LGTM

[eslintbot]

LGTM

[JamesHenry]

I rebased against master as it was a little bit behind

[soda0289]

Thanks for looking into this. Just to confirm the change now uses the colon token as the initial start value of the type annotation node.

[JamesHenry]

@soda0289 Yes, purely based on Flow's precedent of doing that

[JamesHenry]

Based on a really quick check, it seems like this change will not require any updates to prettier which is a bonus.

[JamesHenry]

@Andy-MS Please could you take a look at this also? This would be a solution to https://github.com/JamesHenry/tsep-babylon-test/issues/19

See above for the precedent set by flow, I think it differs slightly from babylon's current output

[soda0289]

I have not tested this with eslint yet, not sure if any rules will fail. Will try it out tonight

[JamesHenry]

@soda0289 Did you get chance to try it out? How did/were you planning on evaluating it out of interest? Do you have a particular repo set up?

[soda0289]

Sorry forgot about this. Was a little busy last week. I have several repos at work that I can run this change under and make sure there are no crashes or false positives.

[soda0289]

@JamesHenry
This does cause an issue with the eslint-plugin-typescript. The rule typescript/type-annotation-spacing has false positives. Which makes sense since we are changing how the type annotation range is calculated.

[JamesHenry]

I think that plugin currently has a number of issues right? I would think it should be pretty straightforward to fix

[soda0289]

Yes the plugin does have several issues. Should be good to merge this too.

[eslintbot]

LGTM