add first test cases related to the 'paths' config
Note that the test cases and configuration format is not the same as the
original ESLint rule.
What is the oxc team strategy to develop such a rule? Is it ok to adapt
the config format ?
---
I started a discussion here :
https://github.com/oxc-project/oxc/discussions/7534#discussion-7574282
I copy/paste the content here. Maybe it is more relevant?
I am working to implement [this no-restricted-imports
rule](https://eslint.org/docs/latest/rules/no-restricted-imports).
I have several problems:
How to handle multiple format configuration in rust?
The eslint config can be: "fs", ["fs"], or {paths: [{name: "fs"}]}. But
Rust needs only one type. I don't know how to do this in rust.
Is it ok to cover only the {paths: [{name: "fs"}]} case ?
How to parse this config with the from_configuration method?
Here is what I have done:
```
fn from_configuration(value: serde_json::Value) -> Self {
let mut paths = Vec::new();
let mut patterns = Vec::new();
if let Some(obj) = value.as_object() {
// Handle paths array
if let Some(paths_value) = obj.get("paths") {
if let Some(paths_array) = paths_value.as_array() {
for path_value in paths_array {
if let Ok(path) = serde_json::from_value(path_value.clone()) {
paths.push(path);
}
}
}
}
// Handle patterns array
if let Some(patterns_value) = obj.get("patterns") {
if let Some(patterns_array) = patterns_value.as_array() {
for pattern_value in patterns_array {
if let Ok(pattern) = serde_json::from_value(pattern_value.clone()) {
patterns.push(pattern);
}
}
}
}
}
Self { paths, patterns }
}
````
But here is my result:
```
[RestrictedPath { name: "foo", import_names: None, message: None }]
-------- rule config --------
{
"paths": [
{
"name": "foo",
"importNames": [
"AllowedObject"
]
}
]
}
```
Note the "None" values
Support `private_fields_as_properties` assumption in class properties transform. This assumption is also enabled by the transform's `loose` option.
Optional chain (e.g. `this?.#prop`) is not yet implemented, but all other usages of private fields are supported. We'll handle optional chain in a follow-on PR.
`TraverseCtx::is_static` was only used in logical assignment operators transform, and #7745 removed that usage. So remove this method. `TransformCtx::duplicate_expression` fulfills the same role.
`TransformCtx::duplicate_expression` (introduced in #7754) don't create temp vars for literals. This produces more compact output for the logical assignment operators transform.
This diverges from Babel (it's better!) so add an override for one of Babel's fixtures. Also add further tests for all literal types.
Use `TransformCtx::duplicate_expression` (introduced in #7754) to decide when to create temp vars for member expression object and computed property.
This fixes a bug where `IdentifierReference`s created when transforming `key` in `object[key] &&= value` were created without a `ReferenceId` (due to `clone_in`).
We didn't catch this before because Babel's test fixtures only cover `object[key++] &&= value` not the simpler `object[key] &&= value`. Add tests for this.
`TransformCtx::duplicate_expression` method introduced in #7754 don't create a temp var for `super`. This prepares it for use in logical assignment operator transform (#7745).
`TransformCtx::duplicate_expression` method introduced in #7754 take a param `mutated_symbol_needs_temp_var`.
If `true`, `duplicate_expression` will create a temp var for an `IdentifierReference` whose's symbol is assigned to elsewhere in the AST. If `false`, it won't.
This is required because different transforms which use `duplicate_expression` have different requirements.
Move implementation of `duplicate_object` from the class properties transform into `TransformCtx::duplicate_expression`, so it can also be used in other transforms.
Tiny refactor. `contains` is clearer than `intersects`, and they produce equivalent assembly when argument is a single flag value, and statically knowable.
https://godbolt.org/z/bTdfbv3f8
Optimization. Inline `enter_expression` visitor, and reduce the size of the function, to keep the path for "nothing to do here, bail out" as fast and compact as possible.
From CodSpeed results, it looks like `enter_expression` was already being inlined as perf gain is not the usual +5% we see for inlining `enter_expression` when it wasn't already. But reducing the size of the visitor function still nets a +1% perf gain.
I added the test cases from
[eslint-plugin-react/jsx-uses-vars](https://github.com/jsx-eslint/eslint-plugin-react/blob/master/tests/lib/rules/jsx-uses-vars.js)
to a `react.rs` file in the `no_unused_vars` tests module.
After adding the new tests, they immediately passed without any source
code changes required. It would seem that the linter already supported
this rule, but now there will be tests to support it.
---------
Co-authored-by: Cameron <cameron.clark@hey.com>
When create a `_super` function outside class, ensure it's always strict mode. The code it contains was previously inside the class, so was strict mode.
Follow-on after #7697.
`transform_assignment_target` is inlined into `enter_assignment_target` visitor, so we want it to be as small as possible. Move assigning to `target` into `transform_assignment_target_impl`, which is the cold path.
The principle is that in the transformer the most important thing for performance is to optimize for the path which is "nothing to do here, exit".
Here we are only transforming `object.#prop`, but very few `AssignmentTarget`s are `object.#prop`, so 99% of the time there is nothing to do. So we want to keep that "do nothing and exit" path as fast and small as possible.
In practice, the `*target =` assignment is only a single assembly operation, so this PR is a micro-optimization. But why not? Every little helps.
