search

eslint / typescript-eslint-parser

An ESLint custom parser which leverages TypeScript ESTree to allow for ESLint to lint TypeScript source code.
Other
915 stars 92 forks source link

Breaking: typescript-estree to 7.0.0 and typescript to 3.2.1 #584

Closed armano2 closed 5 years ago

armano2 commented 5 years ago

This PR contains changes from #576 and deprecates changes from #581

recently i started fixing issues in typescript-estree (most of changes are improvements to typing and tests)

but there was important changes to generated AST:

closes: #581, #576 fixes: #414, #588, #384

platinumazure commented 5 years ago

I'll try to review this tomorrow. Sorry for the delay!

platinumazure commented 5 years ago

Hi @armano2, should this be closed now that #589 has been created?

armano2 commented 5 years ago

depends how you want to release it, if you prefer doing smaller patches, you can release them one by one. and i will rebase changes.

platinumazure commented 5 years ago

@armano2 I don't see much value in releasing with typescript-estree 7.x unless there is a good chance that there are people in the community who are using typescript-estree 7.x for their projects, are currently blocked from using ESLint since we (typescript-eslint-parser) are still on a 5.x version, and would also be blocked from upgrading if we went straight to 8.x. If there isn't that explicit need to provide some support for 7.x, I would rather just jump straight to 8.x since it's a bit less work on the maintenance side.

@kaicataldo @mysticatea What do you think of the above? Should we cut a major release of typescript-eslint-parser with typescript-estree 7.x support "just in case", or can we jump to 8.x? And if we want to support 7.x as well, should we do a release with 6.x before that?

JamesHenry commented 5 years ago

@platinumazure I'm sorry for the noise - it's purely down to this project and typescript-estree having very different approaches to releases.

I wanted typescript-estree to be a low touch as possible - there is a strict following of semver, and semantic-release handles everything automatically upon merge to master.

I would strongly suggest the "major" version of TypeScript is used as the source of truth (TypeScript does not follow semver, so this is not all that intuitive, but major in terms of TypeScript effectively refers to the second digit. E.g. the parser would move from supporting X.1 to X.2)

Please let me know if you want to discuss it any further.

For these PRs specifically, I see no reason not to jump straight to the latest typescript-estree, as the version of TypeScript which is targeted/supported has not changed. It's just that we have been refining the AST structure a lot recently, and all changes are released as individual major version bumps.

I am doing a similar (on the face of it) large jump in Prettier right now: https://github.com/prettier/prettier/pull/5728 - as you can see the amount of changes needed are not as intense as you might have initially expected from v6 -> v13

kaicataldo commented 5 years ago

As far as upgrading typescript-eslint goes, I like the idea of tracking the supported version of TypeScript (following the version of semver that TS follows as described by @JamesHenry).

JamesHenry commented 5 years ago

Closing in favour of https://github.com/eslint/typescript-eslint-parser/pull/596