Add a no-op placeholder method for transforming private fields as `AssignmentPattern`s. e.g. `[object.#prop] = []`.
Implementation will be added later.
Fix edge case in class static properties transform. When transforming `super()` in class constructor, stop searching when hit a `TSModuleBlock`. `TSModuleBlock` is essentially a function, so `super()` there is invalid.
implementing the rule [prefer set
has](https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/prefer-set-has.md)
from unicorn.
I put the fix as dangerous fix because they was no test for the fix on
the unicorn part. I did add some test for this but i'm not sure that i'm
covering everything.
---------
Co-authored-by: Boshen <boshenc@gmail.com>
Co-authored-by: Cameron Clark <cameron.clark@hey.com>
Add class properties transform.
Implementation is incomplete. Notable missing parts:
* Scopes are not updated where property initializers move from class body into class constructor / `_super` function.
* Does not handle binding shadowing problems when property initializers move from class body into class constructor.
* `this` and references to class name in static property initializers need to be transformed to point to a temp var.
* Not all usages of private properties are supported (see below).
* Code which is moved to outside of class body is not transformed by other transforms for class declarations (works OK for class expressions). This includes static property initializers, static blocks, and computed property/method keys.
* Only basic checks for whether computed property/method keys may have side effects.
* Numerous other small issues noted in TODO comments through the code.
### Private properties
Currently does not handle the following usages of private properties:
```js
class Class {
#prop;
static #static;
method() {
object?.#prop;
object?.#prop();
[object.#prop] = [1];
({x: object.#prop} = {x: 1});
object.#prop`xyz`;
object?.#static;
object?.#static();
[object.#static] = [1];
({x: object.#static} = {x: 1});
object.#static`xyz`;
}
}
```
A test case for `new Object()` has been commented out:
This is due to the test configuration specifying `globals: { Object:
"off" }`.
This approach follows the example set by the no_new_wrappers rule.
[Reference
Code](bf839c1dfa/crates/oxc_linter/src/rules/eslint/no_new_wrappers.rs (L88))
---------
Co-authored-by: no-yan <63000297+no-yan@users.noreply.github.com>
Co-authored-by: Cameron Clark <cameron.clark@hey.com>
closes#7434
i couldn't test this. but what's happening is semaitc is being build
without scope child ids. When exhaustive_deps tries to access it its an
empty vec - hence the panic
When I was handling plugin-related diagnostics in `rolldown`, I
encountered this issue.
If there is a define key like `a.6.b`, the error message states that
<code>\`a.6.b\` is not an identifier</code>. However, it should actually
be that <code>\`6\` is not an identifier</code>.
`IdentifierReference::is_global_reference` and `MaybeBoundIdentifier::from_identifier_reference` both look up the symbol for the identifier. Do this lookup only once, rather than twice.
Remove uesless const declaration, since they need to access flags, so
they should never be evaluated in compiling time.
Or does this keyword have some other functions I missed?
Fixed a bunch of semantic errors by removing moving binding logic 😢. This plugin constructs a complex `for-await` replacement so that I wrongly move to an incorrect scope.
- fixes https://github.com/oxc-project/oxc/issues/7365
currently, we are matching globs on the absolute path to the file, which means that in order to properly match, all globs would need to start with `**/`. this is not consistent with the behavior in ESLint, which is defined here: https://eslint.org/docs/v8.x/use/configure/configuration-files#how-do-overrides-work
> **The patterns are applied against the file path relative to the directory of the config file.** For example, if your config file has the path `/Users/john/workspace/any-project/.eslintrc.js` and the file you want to lint has the path `/Users/john/workspace/any-project/lib/util.js`, then the pattern provided in `.eslintrc.js` is executed against the relative path `lib/util.js`.
This PR adds the ability to store the path to the configuration file along with the configuration data, so that we can later use it to resolve the relative paths of the files in the overrides section.
I'm not exactly sure if this will still make sense with nested configuration files, but I think it makes sense to store a path to each configuration file, alongside where the overrides are stored.
`IdentifierReference::is_global_reference` and `MaybeBoundIdentifier::from_identifier_reference` both look up the symbol for the identifier. Do this lookup only once, rather than twice.