## Summary
- Add check to error on `using` declarations at the top level of scripts
- `using` declarations require block scope semantics and are not allowed
at the top level of scripts
`using` declarations are allowed:
- At the top level of ES modules
- At the top level of CommonJS modules (files are wrapped in a function)
- Inside any block scope in scripts
But NOT at the top level of scripts.
Closes#11862
## Test plan
- [x] Added test case
`tasks/coverage/misc/fail/script-top-level-using.js` for invalid usage
- [x] Added test case
`tasks/coverage/misc/pass/script-using-in-block.js` for valid usage in
block
- [x] All existing tests pass
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Summary
- Add `ModuleKind::CommonJS` variant to support CommonJS module type in the parser
- Enable top-level `return` statements (CommonJS files are wrapped in a function)
- Enable top-level `new.target` (allowed in CommonJS function wrapper)
- Add proper errors for `import`/`export` statements in CommonJS
- Add proper errors for `import.meta` in CommonJS
The CommonJS source type can be set via:
- `SourceType::with_commonjs(true)` method
- Babel's `sourceType: "commonjs"` option
Closes#16200
## Test plan
- [x] Added test cases in `tasks/coverage/misc/pass/` for valid CommonJS features
- [x] Added test cases in `tasks/coverage/misc/fail/` for invalid CommonJS usage
- [x] Enabled Babel conformance tests for `sourceType: "commonjs"`
- [x] All existing tests pass
🤖 Generated with [Claude Code](https://claude.com/claude-code)
The parser was not detecting `import type foo, {} from 'bar';` and `import type A, * as NS from 'mod';` as errors. TypeScript's TS1363 requires that type-only imports specify either a default import or named/namespace bindings, but not both—even when the named bindings list is empty.
## Changes
- **Parser**: Added TS1363 check in `parse_import_declaration_specifiers` when encountering `LCurly` or
`Star` token after a type-only default import
- **Module record**: Removed redundant TS1363 validation that couldn't detect empty `{}` cases
- **Error span**: Now points at the default specifier instead of the entire import statement
## Examples
The following patterns now correctly error with TS1363:
```typescript
// Empty named bindings
import type foo, {} from 'bar';
// Named bindings with specifiers
import type foo, { bar } from 'baz';
// Namespace import
import type A, * as NS from 'mod';
```
The parser-level check is comprehensive and catches all cases including
empty braces and namespace imports, which weren't being detected
previously.
- Fixesoxc-project/oxc#17684
---------
Signed-off-by: Cameron <cameron.clark@hey.com>
Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>
Co-authored-by: camc314 <18101008+camc314@users.noreply.github.com>
Co-authored-by: Cameron <cameron.clark@hey.com>
Improved error message for `yield` as identifier usage.
**Before**
```
× Cannot use `yield` as an identifier in a generator context
╭─[test262/test/language/expressions/generators/yield-weak-binding.js:17:33]
16 │
17 │ var g = function*() { yield 3 + yield 4; };
· ─────
╰────
```
**After**
```
× Cannot use `yield` as an identifier in a generator context
╭─[test262/test/language/expressions/generators/yield-weak-binding.js:17:33]
16 │
17 │ var g = function*() { yield 3 + yield 4; };
· ─────
╰────
help: Wrap this in parentheses if you want to use a `yield` expression here
```
Follow-on after #16840 and #16857. We had a few test cases relating to the same thing, and one of them called the undescriptive `oxc.js`. Combine them, and rename the test case files with a more accurate name.
Fixes#16839.
Make parser parse `let?.x` successfully.
There's a failure in codegen idempotency tests, but that's an unrelated
and pre-existing bug, so am leaving that to another PR.
Co-authored-by: overlookmotel <theoverlookmotel@gmail.com>
Improved the error message when JSX syntax is found while not enabled.
The idea came from esbuild's error message ([esbuild try](https://esbuild.github.io/try/#dAAwLjI3LjAAAGV4cG9ydCBjb25zdCBmb28gPSA8Rm9vIC8+Ow)).
**Before**
```
x Unexpected token
,-[:1:20]
1 | export const foo = <Foo />;
: ^
`----
```
**After**
```
× Unexpected JSX expression
╭─[misc/fail/jsx-in-js.js:1:20]
1 │ export const foo = <Foo />;
· ───────
╰────
help: JSX syntax is disabled and should be enabled via the parser options
```
Improves error message for imbalanced tokens.
```
× Expected `,` or `]` but found `const`
╭─[misc/fail/imbalanced-array-expr.js:2:1]
1 │ const foo = [0, 1
· ┬
· ╰── Opened here
2 │ const bar = 2
· ──┬──
· ╰── `,` or `]` expected
╰────
```
The error message for this case was:
```
x Expected `,` but found `const`
,-[:2:1]
1 | const foo = [0,1
2 | const bar = 2
: ^^|^^
: `-- `,` expected
`----
```
This change makes it clear why the parser is expecting `,` and also tell that it can be fixed by adding the closing token somewhere.
Improve error message for missing alternative for conditional expressions.
```
× Expected `:` but found `EOF`
╭─[misc/fail/missing-conditional-alternative-type.ts:2:1]
1 │ type A = 1 extends 2 ? 3
· ┬
· ╰── Conditional starts here
╰────
× Expected `:` but found `EOF`
╭─[misc/fail/missing-conditional-alternative.js:2:1]
1 │ const foo = 1 ? 2
· ┬
· ╰── Conditional starts here
╰────
```
Without this PR, the error mesage is a simple ``Expected `:` but found `EOF` `` only.
Fixes#13284.
Fix semantic's checking of `super()` and `super.prop`.
This fixes various TS test cases, notably correctly identifying that these are all illegal:
```js
class C {
prop = function() { super.foo };
[super.foo]() {}
@super.foo method() {}
};
```
It also fixes various edge cases related to classes nested within other classes that aren't covered by existing conformance tests.
It's pretty much a complete re-write. I've combined the 2 paths for in a class and not in a class into one, to avoid repeated code.
This PR includes pass + fail test fixtures which include `super` in every conceivable position I could think of. There are so many errors in the fail test fixtures, that I had to write a script to check the snapshot includes them all!
Hopefully this solves this issue for once and for all!
Note: The large pass fixture seems to be revealing bugs somewhere in transformer - there's a mismatch, as well as lots of wrong scopes. But that's incidental to this PR, and can be addressed separately.
Follow up to #13368.
Closes#11713 by fixing five more cases mentioned in
https://github.com/oxc-project/oxc/issues/11713#issuecomment-3239687597.
Other changes:
- Added TS(1024) diagnostic
- Fixed the broken oxc-11713-13.ts test file
- Made TS(1070) not report redundantly if it's actually the
responsibility of TS(1071)
- Branch off the more specific TS(1028) diagnostic from the general
TS(1030) diagnostic like TypeScript does
- Remove incorrect code to parse modifiers on typescript this parameter
Closes#12816.
Alternative to #13460.
This PR is the slightly cleaner way to fix the issue compared to the
other PR, but comes at a potential performance cost because now instead
of remembering how many errors there were, we are storing a clone of all
errors and re-assign them when rewinding.
This makes it possible to fix the issue because now even errors before a
checkpoint, that were popped/removed after the checkpoint, are properly
rewinded.
### Changes
- Added all 22 examples of #11713 to `tasks/coverage/misc/fail`
- Added `Default` and `Export` to modifiers
- Added three new TS diagnostics: 1029, 1031, and 1070
- Split off `FunctionKind::Constructor` from `FunctionKind::ClassMethod`
to differentiate when verifying modifiers of formal parameter
- Added multiple checks to verify modifiers
### Results
- "Negative Passed" percentage of `parser_babel.snap` and
`parser_typescript.snap` increased
- Better diagnostic messages in both snapshots
- All new failing examples of original issue do really fail
- Closes#11713
---------
Co-authored-by: Boshen <boshenc@gmail.com>
closes#13284
Either TypeScript implemented the spec incorrectly or made it more
strict.
```js
class C {
foo() {
return {
bar() {
super.bar(); // syntax error in ts but not in js
},
};
}
}
```
Boshen