RFC: Deprecate array prototype extensions #1
Conversation
Co-authored-by: Chris Krycho <hello@chriskrycho.com>
Co-authored-by: Chris Krycho <hello@chriskrycho.com>
Co-authored-by: Chris Krycho <hello@chriskrycho.com>
Co-authored-by: Chris Krycho <hello@chriskrycho.com>
Please enter the commit message for your changes. Lines starting
|
|
||
| Rule `ember/no-array-prototype-extensions` is available for both [eslint](https://github.com/ember-cli/eslint-plugin-ember/blob/master/docs/rules/no-array-prototype-extensions.md) and [template lint](https://github.com/ember-template-lint/ember-template-lint/blob/master/docs/rule/no-array-prototype-extensions.md) usages. Rule examples have recommendations for equivalences. | ||
|
|
||
| We can leverage the fixers of lint rule to auto fix some of the issues. We will also create codemods to help with this migration. |
There was a problem hiding this comment.
Have you done any research yet into what can and cannot be codemodded, and what the level of reliability of those codemods is? If so, that would be great to add here.
There was a problem hiding this comment.
Will a codemod have any runtime information available (beyond just the static analysis that's available in a lint rule)? If so, it would be more useful than just a lint rule autofixer. If not, or either way really, I'd love to see as much autofixing capability added to the lint rule ember/no-array-prototype-extensions as possible. Note that the lint rule employs a variety of heuristics to avoid false positives given the limitations of static analysis.
There was a problem hiding this comment.
@bmish I don't think so, unless we did a telemetry-powered codemod like the native class codemod did. Which is doable, but also a lot more effort.
There was a problem hiding this comment.
I see, then personally I think it'd be worth focusing on building out the lint rule autofixer, as that would be easily accessible to basically all Ember users who will already have eslint-plugin-ember installed and integrated into their IDE/tooling.
There was a problem hiding this comment.
@bmish an auto-fixer is good, but it also has significant limitations: part of the trick here is the way these methods continue to exist on EmberArray. I am talking separately with the Framework team about whether we can deprecate or otherwise separate that out in the period between now and 5.0, because of exactly this complexity and entanglement. 😩
There was a problem hiding this comment.
Thank you folks, I just opened the PR in public repo, emberjs#848 let's move our discussions there! @chriskrycho @bmish
Co-authored-by: Chris Krycho <hello@chriskrycho.com>
|
Open in public |
We are moving away from prototype extensions.
Rendered