📎 ImplementuseConsistentNewBuiltin - unicorn/new-for-builtins

[minht11]

Description

Implement unicorn/new-for-builtins

[minht11]

I will try to work on it myself.

[Conaclos]

Note that new Symbol and new BigInt are already forbidden by noInvalidNewBuiltin.
Thus, this rule should not cover these two cases.

Also, I propose a more consistent name with our existing rules: useConsistentNewBuiltin.

[ematipico]

Why "Consistent" @Conaclos ? I think useNewBuiltin is enough.

[Conaclos]

Taking a closer look at the rule, the following constructors cannot be instantiated without new.

• ArrayBuffer
• BigInt64Array
• BigUint64Array
• DataView
• FinalizationRegistry
• Float32Array
• Float64Array
• Int16Array
• Int32Array
• Int8Array
• Promise
• Proxy
• Set
• SharedArrayBuffer
• Uint16Array
• Uint32Array
• Uint8Array
• Uint8ClampedArray
• WeakMap
• WeakRef
• WeakSet

Since we have noInvalidNewBuiltin, we should certainly have something like noInvalidBuiltinInstatiation.
However, I doubt the usefulness of having three rules.
I think we should deprecate noInvalidNewBuiltin and simply handle Symbol and BigInt in useConsistentNewBuiltin.

Alternatively we could deprecate noInvalidNewBuiltin and create two rules: useConsistentBuiltinInstatiation and noInvalidBuiltinInstatiation.

Any opinion?

Why "Consistent" @Conaclos ? I think useNewBuiltin is enough.

Became I was thinking about useConsistentBuiltinInstatiation.
You are right we should certainly use useConsistentBuiltinInstatiation or useNewBuiltin.
Any preference?

[minht11]

I slightly prefer useConsistentBuiltinInstatiation even if it is bit long, since rule as it currently is dissallows use of new keyword in some cases, so it is bit more clear. noInvalidNewBuiltin deprecation also makes sense to me since they effetively do the same thing, but I will wait for confirmation before renaming things.