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

Add location information to parsing errors #7314

Merged
merged 1 commit into from
Feb 4, 2018

Conversation

kaicataldo
Copy link
Member

Q                       A
Fixed Issues? refs babel/babel-eslint#573 (comment)
Patch: Bug Fix? No
Major: Breaking Change? No
Minor: New Feature? Yes
Tests Added + Pass? Yes
Documentation PR
Any Dependency Changes? No
License MIT

As discussed in Slack, this PR retains location information for errors thrown by the parser and adds error codes so that the consumer can distinguish between errors easily.

A few questions I have:

  1. Did I miss any spots?
  2. Should we be exposing these error codes as constants that a consumer can import so they don't have to care about Babel changing these strings? With only two errors codes, maybe this isn't necessary. They're also shared across packages, so I'm not sure how the team would want to go about that.
  3. I didn't update any tests - should I have?

@babel-bot
Copy link
Collaborator

babel-bot commented Feb 2, 2018

Build successful! You can test your changes in the REPL here: https://babeljs.io/repl/build/6791/

@@ -110,6 +109,7 @@ function parser(pluginPasses, options, code) {
err.message =
`${options.filename || "unknown"}: ${err.message}\n\n` + codeFrame;
}
err.code = "BABEL_PARSE_ERROR";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know if this is the first time we started doing this but are we going to have some kind of convention for this, docs? Or is this just a one-off @loganfsmyth

Copy link
Member

@loganfsmyth loganfsmyth Feb 2, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think error codes are good. Probably in the long run anywhere we throw an error in babel-core should have its own code. Even better would be if Babylon already included a code and this code checked

if (err.code === "BABYLON_PARSE_ERROR")

then Babel wrapped it somehow, but eh :)

Copy link
Member

@hzoo hzoo Feb 2, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok yeah ^ was what I was thinking. maybe @kaicataldo can you make an issue about that? I think a task could be to look through all the places we throw and to think about if we want to make an errors file kind of deal, etc. And I think we would want this to be consistent moving forward and to be more maintainable?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be great to make this consistent! Would this be just for Babylon and babel-core? Or all packages?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's funny also because I'm reminded we have a package called babel-messages that we sometimes use?

err.message += "\n" + codeFrameColumns(code, { start: loc });
err.code = "BABEL_PARSE_ERROR";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this isn't the user's own code failing parsing, I'd vote for this having a different code like BABEL_TEMPLATE_PARSE_ERROR or something.

@hzoo hzoo added the PR: Bug Fix 🐛 A type of pull request used for our changelog categories label Feb 2, 2018
@kaicataldo
Copy link
Member Author

Updated!

@existentialism existentialism merged commit 7234442 into babel:master Feb 4, 2018
kaicataldo added a commit that referenced this pull request Feb 5, 2018
@kaicataldo kaicataldo deleted the parser-error-loc branch February 5, 2018 03:42
@kaicataldo
Copy link
Member Author

Whoops - was trying to delete the branch, not revert the merge!

aminmarashi pushed a commit to aminmarashi/babel that referenced this pull request Mar 17, 2018
@lock lock bot added the outdated A closed issue/PR that is archived due to age. Recommended to make a new issue label Oct 5, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
outdated A closed issue/PR that is archived due to age. Recommended to make a new issue PR: Bug Fix 🐛 A type of pull request used for our changelog categories
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants