## Summary
This PR adds `optimizeEnums` and `optimizeConstEnums` options to the playground's transformer configuration, enabling TypeScript enum optimization features that are already available in the transformer.
## Changes
- Added `optimize_enums: bool` and `optimize_const_enums: bool` fields to the `OxcTransformerOptions` struct in `napi/playground/src/options.rs`
- Updated `apply_transformations` method in `napi/playground/src/lib.rs` to apply these options to `options.typescript.optimize_enums` and `options.typescript.optimize_const_enums`
## Reference
Resolves https://github.com/oxc-project/oxc/blob/d1cf22efc2bc9cf9fa82e887c34965d2ce3004c3/napi/playground/src/options.rs#L59
These options enable:
- `optimize_enums`: Optimize regular (non-const) enums by inlining their member accesses at usage sites when the member value is statically known
- `optimize_const_enums`: Optimize const enums by inlining their values at usage sites and removing the enum declaration
It hadn't been updated for some time, so I made it compatible with the latest state.
(I also want to stop manual mapping, but we are not yet ready for that...)
Follow-on after #16383 and #16403.
While working on those I discovered an option NAPI-RS has to represent `Option::None` as `null`, instead of omitting the field entirely.
Use that option on the structs used for transferring errors and module record over to JS.
I think this is likely more performant because:
1. NAPI-RS can create all properties of the objects using only the faster `node_api_create_object_with_properties` API.
2. It produces consistent object shapes, so JS engine can better optimize code using these objects.
It also brings the shape of the data perfectly into line between standard transfer and raw transfer, and is consistent with how empty fields in the AST are represented as `null`.
I would have used this option before if I'd known it existed.
### Breaking change
I've marked this as a breaking change because code consuming these objects would now need to check for empty fields with `value === null` instead of `value === undefined`.
However in practice, most people probably use `!value` or `value ?? ...`, so it's unlikely to affect many users. This only affects module record and errors anyway, not the AST itself, as we transfer that as JSON, not via NAPI.
## Summary
- Add `cfg` field to `OxcRunOptions` to control Control Flow Graph generation in semantic analysis
- Replace hardcoded `with_cfg(true)` calls with configurable `run_options.cfg` option
- Update TypeScript definitions to include the new `cfg` boolean field
## Motivation
Previously, CFG generation was always enabled (`with_cfg(true)`) in both the main semantic analysis and linter semantic analysis. This change allows users to control CFG generation for better performance when CFG data is not needed.
## Changes
- **napi/playground/src/options.rs**: Add `cfg: bool` field to `OxcRunOptions` struct
- **napi/playground/src/lib.rs**:
- Update `build_semantic` method to use `run_options.cfg` instead of hardcoded `true`
- Update `run_linter` method to use `run_options.cfg` instead of hardcoded `true`
- **napi/playground/index.d.ts**: Add `cfg: boolean` to TypeScript definitions
## Test plan
- [ ] Verify compilation succeeds
- [ ] Test NAPI playground with `cfg: true` (should work as before)
- [ ] Test NAPI playground with `cfg: false` (should skip CFG generation for better performance)
🤖 Generated with [Claude Code](https://claude.ai/code)
## Summary
- Added a new `semanticErrors` field to `OxcParserOptions` to allow users to control whether semantic syntax errors should be checked and reported
- Updated the `build_semantic` method to use this configuration option
- Semantic errors are now only collected when explicitly enabled through the configuration
## Changes
- Add `semantic_errors: bool` field to `OxcParserOptions` struct in `napi/playground/src/options.rs`
- Update `build_semantic` method in `napi/playground/src/lib.rs` to:
- Accept `parser_options` parameter
- Use `parser_options.semantic_errors` for `with_check_syntax_error()`
- Conditionally collect errors based on the configuration
- Auto-generated TypeScript definitions updated to include the new field
## Test plan
Tested manually by creating a simple Node.js script that:
1. Parses code with duplicate variable declarations (semantic error)
2. Tests with `semanticErrors: true` - confirms error is reported
3. Tests with `semanticErrors: false` - confirms no error is reported
The feature works as expected, providing users with control over semantic error checking.
🤖 Generated with [Claude Code](https://claude.ai/code)
When creating bug reports it would be helpful to have a link to a
reproduction that just worked in the browser. By adding the ability to
config Oxlint here, simple reproductions can be done within the
Playground and URLs shared from it.
This would be a lot better if the `config` was a JSON object instead of
a string, but I don't know how to do that only on the Rust side.
An option would be to keep the Rust side a string, but on the browser
side allow it to be an object. Whenever the object changes, we serialize
that to a string before sending it to the Rust side. If there's interest
in this, then I think I can make this change in the playground repo.
Example config and screenshots below.
```json
"linter": {},
```

```json
"linter": {
"config": "{\"plugins\":[\"typescript\"],\"categories\":{\"correctness\":\"error\"},\"rules\":{\"no-debugger\":\"warn\"}}"
},
```

Part of #5068, suggested by @ematipico and @MichaReiser, where @leaysgur
and I explored using biome formatter as the base and made a success. All
credits to the old Rome and the new Biome team.
This PR is in a boilerplate state where some of the functions are marked
as `todo!()`.
I also made the following changes:
* changed the base to be less generic, removed the `Language` and
`Context` generics
* expanded the formatter lifetime to include an `'ast` lifetime
* added access to the source text and comments
* added a mechanism for tracking and accessing parent ast nodes (done by
our codegen)
* removed most of the unit tests because they no longer compile
* removed the `oxc_prettier` crate
playground side PR: https://github.com/oxc-project/playground/pull/71
I went ahead testing out this. Let me know if this is not the plan.
I think the benefit is that this allows rust-side playground code to
reuse some code from other napi crates, for example, `oxc_napi` and
`oxc_parser_napi`. For now, I started as mostly copying paste it and
replacing `#[wasm_bindgen]` with `#[napi]`, but I also used `oxc_napi`
for `OxcError` which replaced diagnostic serialization code from
playground.
---------
Co-authored-by: Boshen <boshenc@gmail.com>