Add eslint-plugin-import to ember-cli blueprint

[bmish]

This RFC proposes adding eslint-plugin-import to the ember-cli blueprint.

I talked to @wycats about this 2 years ago, and he said this was the "most important linter" to add, but mentioned there were some issues that would need to be solved with it. I assume he was referring to the resolver issues, which we are bypassing for now by disabling the import/no-unresolved lint rule.

[NullVoxPopuli]

Did some testing on this plugin today in my own https://github.com/NullVoxPopuli/eslint-configs

import/no-unresolved does not understand package.json#exports -- which is a bit of a deal breaker for modern packages.

I tested with vitest:

eslint-configs/vitest.config.ts
  1:30  error  Unable to resolve path to module 'vitest/config'  import/no-unresolved
# ...
❯ cat node_modules/vitest/package.json | jq '.exports';
{
  ... ✂️...
  "./config": {
    "types": "./config.d.ts",
    "require": "./dist/config.cjs",
    "import": "./dist/config.js"
  }
  

So far, all V2 addons also use package.json#exports

[bmish]

Thanks for testing that. I have updated the RFC to disable the import/no-unresolved lint rule.

[ef4]

I think it's probably not possible to achieve reliable detection of unresolvable imports in traditional apps and addons. People are allowed to emit arbitrary AMD modules from a whole bunch of possible places in the build, across all your addons and their addons, and those are all imports that work at runtime but are totally opaque to a static linter.

In embroider we are stabilizing around having one standardized module resolver that would potentially be able to power a lint rule, but even there when we're looking at a v1 addon or v1 app (and at this point all apps are v1 apps because we haven't done a v2 app format RFC), we never emit resolver failures, because when we run out of possible static places to look we need to assume there might be a runtime answer, so we emit a runtime lookup.

V2 addons do follow strict enough rules that an unresolvable import lint rule can work reliably there. The list of traditional ember-source provided imports is known and hard-coded, and everything else is required to be statically resolvable.

It's possible we'd want to be similarly strict in a v2 app format, as long as we can explain what the upgrade path is such that apps can upgrade even if not every addon has done so.

This RFC is yet another example of something that would be easier to do if we can eliminate the AMD loader.

[NullVoxPopuli]

I'm good with disabling import/no-unresolved 💯 the lint that has helped me out the most is import/no-extraneous-dependencies (or n/no-extraneous-imports) -- it helps folks properly manage their package.json, which can get very messed up in npm and yarn projects.

I'd even be a fan of splitting up the RFC per lint rule, if needed, because the plugin clearly has some good rules that we can use today and can help guide folks towards better configured projects -- all without waiting on v2 stuff

[bmish]

@ef4 thanks for the context. I have updated the RFC to disable the import/no-unresolved lint rule to get around the current infeasibility of reliably resolving imports. We can always come back to it later if it becomes possible, but this unblocks getting the rest of eslint-plugin-import into place.

[wagenet]

We've moved this to Exploring.

[ef4]

I still don't think we can safely implement this until after something like #938 because there's too much stuff that is valid and working but not detectable as a real dependency, even beyond just the standard ember-provided ones.