part of #6274 and #6156
```
/// Treat the source text as `js`, `jsx`, `ts`, or `tsx`.
#[napi(ts_type = "'js' | 'jsx' | 'ts' | 'tsx'")]
pub lang: Option<String>,
```
`Option::get_or_insert_with` is designed for use case where you want to fill an `Option` if it's `None`, and get the contents either way. Use it in transformer where borrow checker allows.
Closes#5020.
`TraverseCtx::generate_uid` and associated methods return a `BoundIdentifier`, containing both symbol ID and name. This reduces boilerplate code for the caller and avoids and unnecessary lookup to get the name.
Also add a couple of helper methods to `BoundIdentifier` to reduce boilerplate further.
Use `BoundIdentifier` to generate `IdentifierReference`s from, instead of cloning `IdentifierReference`s. This simplifies the code and is a less error-prone pattern.
Move post-transform checker into a `tasks` crate. It doesn't feel like it belongs in `oxc_semantic`. It also feels like too heavy a lump of code to put in `tasks/common`.
These are minor changes, and recently I’ve been learning and trying to
implement some features of `oxc_minifier`, which feels a bit complex.
By the way, I’m wondering whether we should gradually add test cases
during the feature implementation process or just copy all the
corresponding tests directly? Perhaps we could implement something like
`rulegen` similar to `linter`?
`TraverseCtx::create_reference_id` is intended for when you don't know if a reference is bound or not. Replace uses of it with the more specific `create_bound_reference_id` and `create_unbound_reference_id`.
I previously extracted the common parts of `prefer_to_be_truthy` and
`prefer_to_be_falsy` into `utils`. However, we should place
rule-specific logic that isn't general-purpose directly within the
respective rules.
Co-authored-by: Don Isaac <donald.isaac@gmail.com>
Probably a very small win, but rather than making lots of small vecs and concatenating, we should just use one vec and then push to it as we visit nodes.
- Renamed the `map_jest` method to make it more clear what it does, now called `map_jest_rule_to_vitest`
- Tried to use a `phf_set!` over a list of strings for checking if we should map rules. Probably not faster, but should be simpler a constant amount of work if we expand the list of rules in the future.
- Made it easier to not mess up the arguments to the `map_jest` function by making it accept a `RuleWithSeverity` instead of just strings.
This PR makes 2 changes to improve the existing API that are not very useful.
- Remove `(Literal)Parser` and `FlagsParser` and their ASTs
- Add `with_flags(flags_text)` helper to `ParserOptions`
Here are the details.
> Remove `(Literal)Parser` and `FlagsParser` and their ASTs
Previously, the `oxc_regular_expression` crate exposed 3 parsers.
- `(Literal)Parser`: assumes `/pattern/flags` format
- `PatternParser`: assumes `pattern` part only
- `FlagsParser`: assumes `flags` part only
However, it turns out that in actual usecases, only the `PatternParser` is actually sufficient, as the pattern and flags are validated and sliced in advance on the `oxc_parser` side.
The current usecase for `(Literal)Parser` is mostly for internal testing.
There were also some misuses of `(Literal)Parser` that restore `format!("/{pattern}/{flags}")` back and use `(Literal)Parser`.
Therefore, only `PatternParser` is now published, and unnecessary ASTs have been removed.
(This also obsoletes #5592 .)
> Added `with_flags(flags_text)` helper to `ParserOptions`
Strictly speaking, there was a subtle difference between the "flag" strings that users were aware of and the "mode" recognised by the parser.
Therefore, it was a common mistake to forget to enable `unicode_mode` when using the `v` flag.
With this helper, crate users no longer need to distinguish between flags and modes.
- fixes https://github.com/oxc-project/oxc/issues/5913
This PR fixes the calculation of spans when dealing with files that have multiple sources and non-zero source start offsets. This is almost always the case for `.vue`, `.astro`, and `.svelte` files. This enables us to correctly apply fixes for these file types both in the CLI with `oxlint` and also in editors like VS Code.
https://github.com/user-attachments/assets/2836c8bd-09be-4e59-801d-7c95f8c2491f
I'm open to ideas on how to improve testing in this area, as I don't think that we currently have any tests for fixing files end-to-end (beyond what the linter rules check). I did run this locally on the gitlab repository (which is written in Vue) and all of the fixes appeared to be applied correctly.
```rs
test("x = ~2147483658.0", "x = 2147483637");
test("x = ~-2147483658", "x = -2147483639");
```
Used `wrapping_neg`, and maybe it is a great solution for #6161.
In common transforms, move all functionality into the `*Store` structs. The `Traverse` impls become just thin wrappers which call into methods on the `*Store` structs.
I think this is clearer because now reading these files from top-to-bottom, you have the code that inserts into the stores before the code that reads from the stores and acts on it.
