import/extensions Restriction

What it does

Some file resolve algorithms allow you to omit the file extension within the import source path. For example the node resolver (which does not yet support ESM/import) can resolve ./foo/bar to the absolute path /User/someone/foo/bar.js because the .js extension is resolved automatically by default in CJS. Depending on the resolver you can configure more extensions to get resolved automatically. In order to provide a consistent use of file extensions across your code base, this rule can enforce or disallow the use of certain file extensions.

Why is this bad?

ESM-based file resolve algorithms (e.g., the one that Vite provides) recommend specifying the file extension to improve performance.

Examples

Examples of incorrect code for this rule:

The following patterns are considered problems when configuration set to "always":

import foo from "@/foo";
import bar from "./bar";
import Component from "./Component";
import foo from "./foo";

The following patterns are considered problems when configuration set to "never":

import express from "express/index.js";
import bar from "./bar.json";
import Component from "./Component.jsx";
import foo from "./foo.js";

Examples of correct code for this rule:

The following patterns are not considered problems when configuration set to "always":

import foo from "@/foo.js";
import * as path from "path";
import bar from "./bar.json";
import Component from "./Component.jsx";
import foo from "./foo.js";

The following patterns are not considered problems when configuration set to "never":

import express from "express/index";
import * as path from "path";
import bar from "./bar";
import Component from "./Component";
import foo from "./foo";

How to use

To enable this rule in the CLI or using the config file, you can use:

CLI

oxlint --deny import/extensions --import-plugin

Config (.oxlintrc.json)

{
  "plugins": ["import"],
  "rules": {
    "import/extensions": "error"
  }
}

References

• Rule Source