Add noObjectAssign Rule to Biome

[kbkn3]

Summary

In light of Biome's plan to support linter rules from other sources (as mentioned in issue #3 "Linter rules from other sources"), I propose including a noObjectAssign rule in the planned ESLint compatibility feature. This rule would discourage the use of Object.assign() in favor of object spread syntax, promoting more modern and readable code.

Motivation

Object.assign() has been widely used for merging objects, but with the introduction of the object spread operator (...) in ECMAScript 2018, we now have a more concise and readable alternative. Encouraging the use of object spread can lead to:

1. More readable and maintainable code
2. Consistency with modern JavaScript best practices
3. Potential performance improvements in some JavaScript engines

Proposal

Add a new lint rule noObjectAssign with the following behavior:

• When enabled, it flags uses of Object.assign() as warnings or errors (configurable)
• It suggests using object spread syntax as an alternative
• Provides an auto-fix option to convert Object.assign() to object spread where possible

Example

// Before (would trigger a warning/error)
const mergedObj = Object.assign({}, obj1, obj2);

// After (suggested fix)
const mergedObj = { ...obj1, ...obj2 };

Configuration

The rule could be configured in the Biome configuration file as follows:

{
  "linter": {
    "rules": {
      "style": {
        "noObjectAssign": "error"
      }
    }
  }
}

Implementation

The implementation would involve:

1. Adding the rule to Biome's linter
2. Implementing the logic to detect Object.assign() usage
3. Creating helpful error messages and suggestions
4. Developing an auto-fix functionality

Potential Challenges

• Handling cases where Object.assign() is used with more than two arguments
• Ensuring that the rule doesn't flag legitimate uses of Object.assign() that can't be easily replaced with object spread

Questions for Discussion

1. Should this rule be part of a broader "prefer modern syntax" ruleset?
2. Are there any edge cases we should consider before implementing this rule?
3. Should we provide an option to ignore certain patterns or usages of Object.assign()?

[ematipico]

We have #3 for this reason: add a comment to add new rules :)

You can close this discussion and add a new comment with exactly this content