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/parserthrow 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 thejsxplugin is enabled.However, we know that JSX elements are _atomic expressions (parsed by the
parseExprAtommethod) and that no other expression can start with<. That method contains a bigswitchstatement, 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:
jsxplugin is not enabled, this code should throw the “nice” error:typescriptplugin is enabled, this code shouldn’t throw because it’s a type parameter:Then, we should make
@babel/corehandle the parser error and suggest the correct@babel/...plugin/preset. You can add the syntax plugin and thereactpreset 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
makeandyarnavailable on your machine)git clone https://github.com/<YOUR_USERNAME>/babel.git && cd babelyarn && make bootstrapmake watch(ormake buildwhenever you change a file)packages/babel-parser/test/fixtures/jsx/errors/_no-plugin,packages/babel-parser/test/fixtures/jsx/errors/_no-plugin-no-jsxandpackages/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-parserto run the testsoutput.jsfiles and run the tests againOVERWRITE=true yarn jest babel-parserand they will be automatically updated.make testto run all the testsgit pushand 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.