Breaking: Use typescript-estree for parsing

[JamesHenry]

Note: There are no known user-facing breaking changes introduced by this PR, but I think it is worth marking it as such to make it clear that a major refactoring has taken place

As approved by the ESLint TSC, this PR:

• Replaces the parsing-related internals with the new typescript-estree package - a drop-in replacement
• Removes the now irrelevant babylon ast-alignment-tests
• Removes any unnecessary dependencies or devDependencies
• Updates the README

As mentioned on gitter, there was only ever one case where we customized the AST for ESLint's benefit previously, and so I have carried over that behaviour by leveraging the ESLint traverser in a post-processing step. Please let me know if there is a better way to maintain this behaviour (without needing to go as far as adding a custom option in typescript-estree).

Thank you ❤️

[JamesHenry]

Btw I would be really happy for other ESLint folks to be invited into the new project!

@kaicataldo You have helped out on this project in various ways, I will add you initially, but feel free to reach out if you would rather not be involved directly

[kaicataldo]

Thanks for doing this work! I have two questions, but I trust your judgment on this one and don't think they're blockers.

Regarding adding me to the repo: if you're looking for someone to commit to maintaining the project right now, I'm unsure of what time commitments I can make at the moment. That being said, I'm happy to be involved and help out where I can!

[JamesHenry]

@kaicataldo

Thanks for doing this work! I have two questions, but I trust your judgment on this one and don't think they're blockers.

Regarding adding me to the repo: if you're looking for someone to commit to maintaining the project right now, I'm unsure of what time commitments I can make at the moment. That being said, I'm happy to be involved and help out where I can!

No, zero expectations for contributions! I just wanted to make it clear that ESLint can be represented :)

[platinumazure]

Left a couple of small change requests (the only thing I really care about is the eslint-disable without a rule name).

Also curious, what about parser services? Did typescript-eslint-parser ever have parser services, or not? I don't see them being returned in parseForESLint, but that's not a problem if there are no parser services in the first place.

[JamesHenry]

@platinumazure No it never actually had any parserServices, they were planned for a while, I even had a PR open, but they never went in, so no changes introduced by this PR.

Thanks a lot for the feedback, I've addressed it, PTAL!

[JamesHenry]

Just FYI I will go through and do some comprehensive issue triage once this change happens, migrating any purely parsing related issues to the other repo

[platinumazure]

LGTM-- thanks for addressing my feedback.

Just one last question-- not a blocker but trying to understand the potential strategic direction of this project. If we were to add parser services, etc., and needed a Typescript compiler instance, how would we do that? Should typescript-estree expose an instance in its API? Should each project depend on typescript (and risk the mismatch of versions)? Should typescript-eslint-parser peer-depend on typescript, and typescript-estree explicitly depend on typescript and satisfy the peer dependency? Etc.

Greatly appreciate your patience as I try to understand more about what this will look like in the future 😄

[JamesHenry]

Right now all the TypeScript dependencies are based on peers, so it would be a single version based on what the user installed, but it is a good point to raise in case that ever changed.

I would definitely be happy to expose the ts.Program instance from the typescript-estree and then that (or a subset of it) could be further exposed via parserServices here. Just let me know (and I have already added @kaicataldo as a collaborator, happy to add anyone else from the team)

Thanks to all of you for the reviews!