eslint-plugin-ember
eslint-plugin-ember copied to clipboard
ember-cli
Not recommended: require-fetch-import
I see that there is a plan to add require-fetch-import to the recommended rule set.
I don't think this is a good idea. It pushes people toward a pattern that we are already trying to kill: importing from paths that aren't real packages.
At a minimum, I don't think we should enable this by default until https://github.com/ember-cli/ember-fetch/issues/330 is addressed.
Personally, I don't think it's appropriate to require people to import fetch at all. It's a web standard, linting against it in people's code is contrary to our efforts to bring ember into better alignment with javascript-ecosystem-wide standards, and the global fetch is equally easy to patch/polyfill in all environments (like tests and fastboot) where it's helpful to do that.
@ef4 sounds good, I will remove that from the plan. Would you like to edit the require-fetch-import rule doc to explain these caveats? That will help make it more clear why some may choose not to use this rule.
FWIW this pushes us towards a vastly different way of writing testing code and if we want move into such a direction where test waiters are no longer a thing it should require an RFC
FWIW this pushes us towards a vastly different way of writing testing code and if we want move into such a direction where test waiters are no longer a thing it should require an RFC
You're misunderstanding me. We can still hook into fetch the exact same way for tests. That has nothing to do with making people type import fetch from "fetch".
An unbound variable named fetch and an import from "fetch" are equally easy to detect and replace with whatever implementation people want, including test waiters. The difference is that one reads as normal web-standards javascript and one requires teaching people why ember is being weird.
Also, if we take control of global fetch, then your test waiters will work even when the fetch is in an NPM package that's not ember-specific.
okay, that sounds reasonable. the rule was built to address issues with the current reality where the global fetch does not integrate with test waiters. if we have plans to improve that then that's fine with me, but until that is the case I would still consider this rule quite useful to avoid flaky tests due to missing test waiters.