📎 Introduce `performance` group and move `noDelete` to new group

[MichaReiser]

Description

Motivation

The noDelete rule isn't about correctness but performance. Using the delete operator in performance sensitive code can result in significantly slower runtime because JIT may de-opt some code (or have to re-JIT code).

That's why the noDelete rule should be moved to the performance group.

See this discussion on more details on why to move the rule.

Task

• Introduce new performance group
• Move noDelete rule to new group
• Improve the wording of the noDelete diagnostic to clearly explain the motivation

[MichaReiser]

There may be some cases where the use of delete has undesired effects [1, 2]

Which may be reason to leave it in the correctness group but we should improve the explanation of the rule

[dhrjarun]

assign this issue to me.

[MichaReiser]

assign this issue to me.

I should have removed the good first issue label when I noticed that there are some correctness problems too. Part of this issue is to reason about whether the rule should be moved into the performance group and how to best explain the correctness issues that may come with the use of delete. Do you feel comfortable diving into this (also see relevant discussion)

[dhrjarun]

Thanks @MichaReiser I will read discussion and let you know.

[dhrjarun]

delete operator can be used incorrectly in the case of

1. deleting a variable

var x = "a"
let y = "b"
const z = "c"

delete x // SyntaxError in strict mode otherwise returns false
delete y // SyntaxError in strict mode
delete z // SyntaxError in strict mode

2. deleting a non-configurable member of object

const app = {}
Object.defineProperty(app, "name", { value: "rome", configurable: false })

delete app.name // TypeError in strict mode otherwise returns false

3. deleting the built in object or its member like Math, Array, will lead to Reference Error in the code.

delete window.Math

Rome parser throws the target for a delete operator cannot be a single identifier for 1st case -- delete x (Playground). Just like this, We can implement the logic in rome_js_parser for checking the 2nd case and throw error if it's in strict mode or warning Otherwise.

So I think we can have a rule lint/correctness/noDeleteNative for for case 3.

Another rule lint/performance/noDelete we can have for performance issue. And we can make this rule recommendation to false. This rule will provide undefined alternative code-action for these.

const obj = { name: ""}
const list = [1, 2, 3, 4]

delete obj.name // valid
delete list[1] // valid

@MichaReiser let me know what do you think

[github-actions[bot]]

👋 @rome/staff please triage this issue by adding one of the following labels: S-Bug: confirmed, S-Planned , S-Wishlist or umbrella