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)
  • Add any to some autofixer for no-array-prototype-extensions rule #1609
  • Add compact to filter autofixer for no-array-prototype-extensions rule #1611
  • Add filterBy to filter autofixer for no-array-prototype-extensions rule #1610
  • Add findBy to find autofixer for no-array-prototype-extensions rule #1614
  • Add getEach to map autofixer for no-array-prototype-extensions rule #1632
  • Add invoke to map autofixer for no-array-prototype-extensions rule #1631
  • Add isAny and isEvery autofixers for no-array-prototype-extensions rule #1630
  • Add mapBy to map autofixer for no-array-prototype-extensions rule #1619
  • Add objectAt autofixer for no-array-prototype-extensions rule #1615
  • Add objectsAt to map autofixer for no-array-prototype-extensions rule #1628
  • Add reject to filter autofixer for no-array-prototype-extensions rule #1629
  • Add rejectBy to filter autofixer for no-array-prototype-extensions rule #1627
  • Add setEach to forEach autofixer for no-array-prototype-extensions rule #1633
  • Add sortBy to sort autofixer for no-array-prototype-extensions rule #1621
  • Add toArray autofixer for no-array-prototype-extensions rule #1616
  • Add uniq autofixer for no-array-prototype-extensions rule #1620
  • Add uniqBy to reduce autofixer for no-array-prototype-extensions rule #1626
  • Add without to filter autofixer for no-array-prototype-extensions rule #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: ember-template-lint/ember-template-lint#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.