Rules that need autofixers

[bmish]

List of rules where it should be easy / practical / useful to implement an autofixer:

• jquery-ember-run
  • Add run loop?
  • Low priority since jQuery use is discouraged already
• no-array-prototype-extensions (one Ember array function at a time)
  • #1609
  • #1611
  • #1610
  • #1614
  • #1632
  • #1631
  • #1630
  • #1619
  • #1615
  • #1628
  • #1629
  • #1627
  • #1633
  • #1621
  • #1616
  • #1620
  • #1626
  • #1617
  • NEVERMIND: Observable properties (see this comment for why it's not easy to autofix these):
    • firstObject
    • lastObject
  • NEVERMIND: MutableArray (see this comment for why it's not easy to autofix these):
    • addObject
    • addObjects
    • clear
    • insertAt
    • popObject
    • pushObject
    • pushObjects
    • removeAt
    • removeObject
    • removeObjects
    • replace
    • reverseObjects
    • setObjects
    • shiftObject
    • unshiftObject
    • unshiftObjects
• no-arrow-function-computed-properties
  • Convert to non-arrow function
• no-function-prototype-extensions
• no-global-jquery
  • Switch to imported jQuery
• no-jquery
  • As described in the rule doc, there's a codemod that helps with this already. Should any of it be incorporated into the rule for convenience or would that duplicate too much? Low priority since codemod already exists.
• use-brace-expansion
  • Adopt brace expansion, share code for this with require-computed-property-dependencies
• no-test-and-then
  • Convert to await
• Others?

This is a good "help wanted" / "first issue" for anyone who wants to help out and claim one or more of these.

Same issue for ember-template-lint: https://github.com/ember-template-lint/ember-template-lint/issues/2571

[bmish]

@tgvrssanthosh I created a list of all the Ember array functions/properties we need to handle to track progress. Thanks for working on this.

[Turbo87]

@bmish it seems a bit dangerous to me to have autofixers for the array prototype rule since we can't actually reliably detect if this rule is a false positive or not. iirc ESLint supports fixers as suggestions too, instead of unconditional replacements. this might be a better option for these cases.

[bmish]

@Turbo87 it's a fair concern. We made the call to proceed with the autofixer because:

1. The autofixer is obviously dramatically more useful in terms of mass migration compared to suggestions which must be applied individually via the editor UI. The autofixer gives us a better chance of successfully moving the community away from array prototype extensions.
2. This rule is now opt-in (no longer recommended) so users would presumably be more thoughtful about enabling it.
3. The rule doc calls out the limitations of the rule regarding false positives in detail. I also previously added heuristics to help mitigate the false positives, although it's not possible to fully mitigate them.
4. We avoided autofixing reactivity/observability-related functions or properties (as called out in the rule doc).

If it still becomes a problem, we could consider adding an option to the rule that controls whether it's an autofix or suggestion.