Note: This uses a regex to replace multiple instances of whitespace with
` .`. May not be the most performant, so if there's a simple alternative
I can change to that instead.
cc @camc314, I know this was assigned to you but I just wanted to throw
something quick together while I had a minute. Feel free to use this, or
decline it and write your own.
Fixes#7794.
---------
Co-authored-by: Cameron Clark <cameron.clark@hey.com>
Sometimes we want to use Babel test's options to test some code, If the example can get the TransformerOptions from Babel options, then we can easily do it
Code in static property initializers moves from inside the class to outside. If environment outside the class is not strict mode, then scopes within the initializer become sloppy mode. Update `ScopeFlags` for scopes in static prop initializers accordingly.
We're following Babel for now, but this isn't actually correct. The initializers should be wrapped in a strict mode IIFE to maintain their strict mode behavior. But at least semantic data is now correct for the output.
The name `is_strict` was misleading for these methods, because it doesn't tell you if the e.g. function *is* strict mode, only whether it contains a `"use strict"` directive. `Function::is_strict` might return `false` for a function which does have strict mode semantics because it's e.g. in an ESM file.
Rename these methods to `has_use_strict_directive` to better reflect what they do.
For `Program`, change the method to only check for `"use strict"` directive and not to look at `source_type`. `Semantic` should be the source of truth on strict/sloppy mode of AST nodes. It's cheaper to look up the `ScopeFlags` than to iterate over `directives`, so don't encourage this anti-pattern by providing a "rival" method.
In two of the overridden text fixtures for class properties transform, there was no `output.js` file because what was overridden was just `options.json` and `update_fixtures.js` script then generated new output files using Babel with the new options.
That was fine, but doesn't work with #7771. So add `output.js` files to the these overrides too.
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.
Babel's tests only cover transforming `this.#prop &&= value` with logical assignment operators transform also enabled. Add tests for just class properties transform alone.
