babel: Better parser error when using jsx
Was checking https://github.com/babel/babel/pull/11478 and testing out syntax and noticed we don’t error with the normal “use this plugin/preset” like we do for proposals with JSX itself. @nicolo-ribaudo mentioned it’s probably since jsx is implemented as a normal plugin so we didn’t have this.expectPlugin("recordAndTuple");
unknown: Unterminated regular expression (1:5)
> 1 | <a></a>
| ^
unknown: Support for the experimental syntax 'pipelineOperator' isn't currently enabled (1:3):
> 1 | a |> b
| ^
Add @babel/plugin-proposal-pipeline-operator (https://git.io/vb4SU) to the 'plugins' section of your Babel config to enable transformation.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 15 (13 by maintainers)
Commits related to this issue
- Add: better parser error when using jsx Address #11499 — committed to penguingovernor/babel by penguingovernor 4 years ago
- Add better parser error when using jsx (#11722) * Add "<" parser tests * No {jsx,flow,typescript} plugin * Type parameter * Valid JS Code * Add: better parser error when using jsx Add... — committed to babel/babel by penguingovernor 4 years ago
This bug needs different steps in order to be fixed, but they can be done in the same PR.
First, we should make
@babel/parser
throw a developer-friendly error. Consider these examples:The first one throws
SyntaxError: Unexpected token (1:0)
, while the second one throws a more actionableSyntaxError: This experimental syntax requires enabling the parser plugin: 'pipelineOperator' (1:2)
. Why this difference? If you search for the"pipelineOperator"
string inpackages/babel-parser/src
, you’ll see that (as @hzoo mentioned above) we are calling thethis.expectPlugin("pipelineOperator")
function when we find the “pipeline” (|>
) operator.We can do something similar for JSX, but it’s harder. The main problem is that checks for ECMAScript proposals (such as
|>
) are inlined in the parser code, while checks for JSX code are only enabled when thejsx
plugin is enabled.However, we know that JSX elements are _atomic expressions (parsed by the
parseExprAtom
method) and that no other expression can start with<
. That method contains a bigswitch
statement, and (at the end) we throwthis.unexpected()
if we don’t find any valid token. We could add a new case and, if the token is<
, callthis.expectPlugin("jsx")
.Here are a few possible tests:
jsx
plugin is not enabled, this code should throw the “nice” error:typescript
plugin is enabled, this code shouldn’t throw because it’s a type parameter:Then, we should make
@babel/core
handle the parser error and suggest the correct@babel/...
plugin/preset. You can add the syntax plugin and thereact
preset atpackages/babel-core/src/parser/util/missing-plugin-helper.js
.If it is the first time that you contribute to Babel, follow these steps: (you need to have
make
andyarn
available on your machine)git clone https://github.com/<YOUR_USERNAME>/babel.git && cd babel
yarn && make bootstrap
make watch
(ormake build
whenever you change a file)packages/babel-parser/test/fixtures/jsx/errors/_no-plugin
,packages/babel-parser/test/fixtures/jsx/errors/_no-plugin-no-jsx
andpackages/babel-parser/test/fixtures/jsx/errors/_no-plugin-ts-type-param
. You can see an example atpackages/babel-parser/test/fixtures/experimental/_no-plugin/import-meta
.yarn jest babel-parser
to run the testsoutput.js
files and run the tests againOVERWRITE=true yarn jest babel-parser
and they will be automatically updated.make test
to run all the testsgit push
and open a PR!@karansapolia it’s yours! let us know (here or on slack) if you have any questions!
Awesome! Please feel free to reach out if you have any questions.
i want to try this.