feat: support BigIntLiteral

[ikatyang]

Ref: prettier/prettier#5545

• require typescript@3.2.0-rc (bitInt was added in TS 3.2)
• update to @babel/parser@7.1.6 (bigInt was added in 7.0.0-beta.48)

[JamesHenry]

This PR allowed me to catch the fact that a lot of ast-alignment tests are currently not being run: #36

[JamesHenry]

That PR has now been merged, it might be that is surfaces some issues with updating the babel parser version, sorry for the confusion.

I am hesitant to break away from our historically consistent approach of waiting until TypeScript versions become stable before supporting them.

Currently semantic-release, the library we use to handle releases here does not automatically support multiple release channels, but it looks like it will really soon! semantic-release/semantic-release#991

Hopefully, therefore, for TypeScript 3.3 we will be able to automate everything and support TypeScript versions all through their prerelease phases, but for TypeScript 3.2, what I'd like to do is create a feature branch, and then once we are happy I will manually publish a release from it under a next tag. Prettier can then consume that until it become stable and we PR the feature branch into master.

Sound good?

[JamesHenry]

I've created the branch: https://github.com/JamesHenry/typescript-estree/tree/ts-3.2

[armano2]

@JamesHenry, why not going other way around? making default branch as stable, and following latests rc/beta changes on separate branch and releasing them as *.*.*-beta.X

[JamesHenry]

I think we are describing the same thing? I am suggesting the base of this PR be changed to the new branch I just created, which will be the source of a new, non-stable distribution on npm.

[ikatyang]

I'm still not sure what should this node look like. @babel/parser parsed them as:

interface BigIntLiteral {
  type: "BigIntLiteral";
  value: string;
  extra: {
    raw: string;
    rawValue: string;
  }
}

but the alignment test rejected the extra field and expected:

interface BigIntLiteral {
  type: "BigIntLiteral";
  value: string;
  raw: string;
}

which is the current implementation.

[JamesHenry]

Hmm yeah seems there isn't quite a consensus yet: estree/estree#169

There hasn't been any update on that issue for a while...

I think the least likely of all is having that extra object involved in ESTree, so maybe we should just ignore the AST comparison for now?

[ikatyang]

extra is already ignored, I just want to make sure if it's fine to output the node that's different from babel's. 😅

typescript-estree/tests/ast-alignment/utils.ts

Lines 102 to 105 in 8e70375

	{
	key: 'extra',
	predicate: always
	},

[JamesHenry]

Yeah I think it's fine, I think we just have to accept that as experimental things get added they may be subject to change.

We can always publish new major versions in future if we need to amend it