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

Make ParseError Much Simpler now that we can use TypeScript #14796

Merged
merged 8 commits into from Jul 25, 2022

Conversation

tolmasky
Copy link
Contributor

@tolmasky tolmasky commented Jul 25, 2022

Q                       A
Fixed Issues? No
Patch: Bug Fix? No
Major: Breaking Change?
Minor: New Feature? No
Tests Added + Pass? Yes
Documentation PR Link N/A
Any Dependency Changes? No
License MIT

As originally promised in the TypeSafe Errors PR, this PR dramatically simplifies all the ParseError machinery now that we are on TypeScript (woooo!!!). From a usability perspective, it is now much easier to define error templates, no longer requiring the use of the weird _() flow-workaround-function. So, before you'd have to do something like this:

const TSErrors = ParseErrorEnum`typescript` (
  (_: typeof toParseErrorCredentials) => ({
    AbstractMethodHasImplementation: _<{
      methodName: string;
    }>(
      ({ methodName }) =>
        `Method '${methodName}' cannot have an implementation because it is marked abstract.`,
    ),
    AccesorCannotDeclareThisParameter: _(
      "'get' and 'set' accessors cannot declare 'this' parameters.",
    ),
    // ...
  }),
);

And now you instead do this:

const TSErrors = ParseErrorEnum`typescript` (
  AbstractMethodHasImplementation: ({ methodName }:  { methodName: string }) =>
    `Method '${methodName}' cannot have an implementation because it is marked abstract.`,
  AccesorCannotDeclareThisParameter: "'get' and 'set' accessors cannot declare 'this' parameters.",
  // ...
});

In other words, we've kept the simplicity of the old object reason-code to message mapping, but with real types. This was of course the original goal, but many flow bugs prevented us from doing this as cleanly, so we needed these weird "carrier" functions (like toParseErrorCredentials) to shuttle the types around. TypeScript is much better at tracking the types everywhere and so we no longer need them and can so we can just use normal objects.

Aside from that, there are just a few random fixes to get rid of ts-expect-errors, etc., and updating comments to reflect the new code.

tolmasky added 7 commits Jul 25, 2022
…ay, and we may want to change this back to string when we allow custom sytnax plugins (or "SyntaxPlugin | string" just to convey this a bit better, even though that would be the same).

Reviewed by @tolmasky.
@tolmasky tolmasky requested review from JLHwung and nicolo-ribaudo Jul 25, 2022
@tolmasky tolmasky changed the title Typescript parse error Make ParseError Much Simpler now that we can use TypeScript Jul 25, 2022
Copy link
Member

@nicolo-ribaudo nicolo-ribaudo left a comment

Awesome, thank you!

packages/babel-parser/src/parse-error/credentials.ts Outdated Show resolved Hide resolved
@liuxingbaoyu liuxingbaoyu added PR: Internal 🏠 A type of pull request used for our changelog categories pkg: parser area: typescript labels Jul 25, 2022
Copy link
Contributor

@liuxingbaoyu liuxingbaoyu left a comment

This PR is great and it looks so much better now!

Copy link
Contributor

@JLHwung JLHwung left a comment

This PR looks great to me.

@tolmasky tolmasky merged commit 24d5fce into babel:main Jul 25, 2022
36 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pkg: parser PR: Internal 🏠 A type of pull request used for our changelog categories
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants