Replies: 2 comments 5 replies
-
For this only, the error is recoverable, you can pass the option As for the others I'm not very familiar with, let's wait for other people's opinions. |
Beta Was this translation helpful? Give feedback.
-
This test262 test states the opposite: We implement the syntax error when we are bumping up the test262 conformance. Since the spec draft has not been updated since Feb 2021, I think we should move the discussion to the spec repo and I believe the champion will clarify that. |
Beta Was this translation helpful? Give feedback.
-
#14668 added a parser error when attempting to do named imports from JSON modules.
I'm confident that this change is in the interest of the community and could be useful to catch errors. However, from a semantic point of view, the spec draft (https://tc39.es/proposal-json-modules/) doesn't forbid
import { foo } from "mod" assert { type: "json" }
as an early error—as such, it should not be a parser error, merely a runtime one. #14668 (review) expressed the same concern but didn't really block the PR on that ground.I often use the Babel parser to explore quirky JS syntax, but if the parser keeps adding early diagnostics for invalid semantics and causes no AST to be generated at all, it makes testing unnecessarily hard, since static semantics are mixed with runtime ones. It also pushes other parsers that aim to align with Babel to implement the same behavior (e.g. typescript-eslint/typescript-eslint#5377 (comment)) —although that's probably a weaker argument.
Is it possible that we defer the error to the generator, and only emit the error when downleveling ES modules to CJS, etc., otherwise leaving the error to the runtime?
Beta Was this translation helpful? Give feedback.
All reactions