Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

extensions and no-unresolved with imports that don't have file extensions #2959

Open
made-in-nz opened this issue Feb 8, 2024 · 3 comments

Comments

@made-in-nz
Copy link

made-in-nz commented Feb 8, 2024

I may be missing something obvious here. In a react project, trying to get a linting error to display when the relative path to the resource is incorrect, but while still allowing the resource to not contain its extension.
Expected: no error expected when RVRModal.jxs exists at the relative path:
import RVRModal from "../../core/components/RVRModal";
Expected: error if there is an incorrect path:
import RVRModal from "../../core/incorrectpath/RVRModal";

Actual (when path is correct):
image

My .eslintrc:

{
	"plugins": [
		"react",
		"import"
	],
	"env": {
		"browser": true,
		"node": true,
		"es2020": true
	},
	"parserOptions": {
		"sourceType": "module",
		"ecmaVersion": 2020
	},
	"extends": [
		"eslint:recommended",
		"plugin:import/recommended",
		"plugin:react/recommended",
		"plugin:react/jsx-runtime",
		"prettier"
	],
	"rules": {
		"no-unused-vars": [
			"warn",
			{
				"ignoreRestSiblings": true
			}
		],
		"react/prop-types": 0,
		"react/no-unescaped-entities": 0,
		"react/display-name": 0,
		"import/extensions": 0
	}
}

If I add "import/no-unresolved": 0 to the rules, then the error disappears but then there is obviously no errors if I enter an invalid relative path to the resource either.
If I remove the "import/extensions": 0 rule, I am then forced to add the file extensions to all of my imports, which I would prefer not to do.

Is there a way for the no-unresolved to function alongside the extensions rule when extensions are disabled?

@ljharb
Copy link
Member

ljharb commented Feb 8, 2024

That should indeed work just fine. I notice you're not defining any settings, and the extensions rule isn't helping to enforce your extension preference.

(I also notice you're using the recommended plugin (from the import and react plugins), which I discourage - you should be using the airbnb config)

@made-in-nz
Copy link
Author

Thanks @ljharb, I'm not in a position now to change to airbnb config but may look at it in future. With my current extends, should this still work?
I see in the docs for the extensions rule, it defaults to "never", meaning it will never display an error for a missing file extension in an import statement. If I change my rules to:

		"import/extensions": [
			"always"
		],
		"import/no-unresolved": 0

I would expect an import without a file extension to receive an error from the import/extensions rule, however I don't get one.
You mention not defining any settings - are there any you'd recommend to get this working?

@made-in-nz
Copy link
Author

Sorry ignore comment above, I didn't realise config on each rule goes in the settings section.
To quickly reproduce with a new Vite project:

$ npm create vite@latest my-app -- --template react-swc
$ cd my-app && npm install
$ npm install -D eslint-plugin-import

Edit .eslint.cjs

  • add "plugin:import/recommended" to the "extends"
  • add
  settings: {
    "import/extensions": [2, "always"],
  },

Now edit main.jsx & remove the ".jsx" extension from the import App line, eg
import App from "./App";

At this point my expectation is that:

  • there will not be any import/extensions error (there is not).
  • there should not be an import/no-unresolved error (there is).

This is a basic example but I would like an eslint error from import/no-unresolved if, for example, the relative path to the resource is incorrect, but there shouldn't be an error if the path is correct & the .jsx file extension is missing.
That does not appear to be possible?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants