Important: This documentation covers Yarn 1 (Classic).
For Yarn 2+ docs and migration guide, see yarnpkg.com.

Package detail

eslint-plugin-import

import-js112.5mMIT2.31.0

Import with sanity.

eslint, eslintplugin, eslint-plugin, es6, jsnext, modules, import, export

readme

eslint-plugin-import

github actions travis-ci coverage win32 build status npm npm downloads

This plugin intends to support linting of ES2015+ (ES6+) import/export syntax, and prevent issues with misspelling of file paths and import names. All the goodness that the ES2015+ static module syntax intends to provide, marked up in your editor.

IF YOU ARE USING THIS WITH SUBLIME: see the bottom section for important info.

Rules

💼 Configurations enabled in.\ ⚠️ Configurations set to warn in.\ 🚫 Configurations disabled in.\ ❗ Set in the errors configuration.\ ☑️ Set in the recommended configuration.\ ⌨️ Set in the typescript configuration.\ 🚸 Set in the warnings configuration.\ 🔧 Automatically fixable by the --fix CLI option.\ 💡 Manually fixable by editor suggestions.\ ❌ Deprecated.

Helpful warnings

Name Description 💼 ⚠️ 🚫 🔧 💡 ❌
export Forbid any invalid exports, i.e. re-export of the same name. ❗ ☑️ | |
no-deprecated Forbid imported names marked with @deprecated documentation tag. | | |
no-empty-named-blocks Forbid empty named import blocks. | | 🔧 💡
no-extraneous-dependencies Forbid the use of extraneous packages. | | |
no-mutable-exports Forbid the use of mutable exports with var or let. | | |
no-named-as-default Forbid use of exported name as identifier of default export. | ☑️ 🚸 | |
no-named-as-default-member Forbid use of exported name as property of default export. | ☑️ 🚸 | |
no-unused-modules Forbid modules without exports, or exports without matching import in another module. | |

Module systems

Name Description 💼 ⚠️ 🚫 🔧 💡 ❌
no-amd Forbid AMD require and define calls. | | |
no-commonjs Forbid CommonJS require calls and module.exports or exports.*. | | |
no-import-module-exports Forbid import statements with CommonJS module.exports. | | 🔧 |
no-nodejs-modules Forbid Node.js builtin modules. | | |
unambiguous Forbid potentially ambiguous parse goal (script vs. module). | |

Static analysis

Name Description 💼 ⚠️ 🚫 🔧 💡 ❌
default Ensure a default export is present, given a default import. ❗ ☑️ | |
named Ensure named imports correspond to a named export in the remote file. ❗ ☑️ | ⌨️ |
namespace Ensure imported namespaces contain dereferenced properties as they are dereferenced. ❗ ☑️ | |
no-absolute-path Forbid import of modules using absolute paths. | | 🔧 |
no-cycle Forbid a module from importing a module with a dependency path back to itself. | | |
no-dynamic-require Forbid require() calls with expressions. | | |
no-internal-modules Forbid importing the submodules of other modules. | | |
no-relative-packages Forbid importing packages through relative paths. | | 🔧 |
no-relative-parent-imports Forbid importing modules from parent directories. | | |
no-restricted-paths Enforce which files can be imported in a given folder. | | |
no-self-import Forbid a module from importing itself. | | |
no-unresolved Ensure imports point to a file/module that can be resolved. ❗ ☑️ | |
no-useless-path-segments Forbid unnecessary path segments in import and require statements. | | 🔧 |
no-webpack-loader-syntax Forbid webpack loader syntax in imports. | |

Style guide

Name Description 💼 ⚠️ 🚫 🔧 💡 ❌
consistent-type-specifier-style Enforce or ban the use of inline type-only markers for named imports. | | 🔧 |
dynamic-import-chunkname Enforce a leading comment with the webpackChunkName for dynamic imports. | | 💡
exports-last Ensure all exports appear after other statements. | | |
extensions Ensure consistent use of file extension within the import path. | | |
first Ensure all imports appear before other statements. | | 🔧 |
group-exports Prefer named exports to be grouped together in a single export declaration | | |
imports-first Replaced by import/first. | | 🔧 | ❌
max-dependencies Enforce the maximum number of dependencies a module can have. | | |
newline-after-import Enforce a newline after import statements. | | 🔧 |
no-anonymous-default-export Forbid anonymous values as default exports. | | |
no-default-export Forbid default exports. | | |
no-duplicates Forbid repeated import of the same module in multiple places. | ☑️ 🚸 | 🔧 |
no-named-default Forbid named default exports. | | |
no-named-export Forbid named exports. | | |
no-namespace Forbid namespace (a.k.a. "wildcard" *) imports. | | 🔧 |
no-unassigned-import Forbid unassigned imports | | |
order Enforce a convention in module import order. | | 🔧 |
prefer-default-export Prefer a default export if module exports a single name or multiple names. | |

eslint-plugin-import for enterprise

Available as part of the Tidelift Subscription.

The maintainers of eslint-plugin-import and thousands of other packages are working with Tidelift to deliver commercial support and maintenance for the open source dependencies you use to build your applications. Save time, reduce risk, and improve code health, while paying the maintainers of the exact dependencies you use. Learn more.

Installation

# inside your project's working tree
npm install eslint-plugin-import --save-dev

Config - Legacy (.eslintrc)

All rules are off by default. However, you may extend one of the preset configs, or configure them manually in your .eslintrc.(yml|json|js).

  • Extending a preset config:
{
  "extends": [
     "eslint:recommended",
     "plugin:import/recommended",
  ],
}
  • Configuring manually:
{
  "rules": {
    "import/no-unresolved": ["error", { "commonjs": true, "amd": true }]
    "import/named": "error",
    "import/namespace": "error",
    "import/default": "error",
    "import/export": "error",
    // etc...
  },
},

Config - Flat (eslint.config.js)

All rules are off by default. However, you may configure them manually in your eslint.config.(js|cjs|mjs), or extend one of the preset configs:

import importPlugin from 'eslint-plugin-import';
import js from '@eslint/js';

export default [
  js.configs.recommended,
  importPlugin.flatConfigs.recommended,
  {
    files: ['**/*.{js,mjs,cjs}'],
    languageOptions: {
      ecmaVersion: 'latest',
      sourceType: 'module',
    },
    rules: {
      'no-unused-vars': 'off',
      'import/no-dynamic-require': 'warn',
      'import/no-nodejs-modules': 'warn',
    },
  },
];

TypeScript

You may use the following snippet or assemble your own config using the granular settings described below it.

Make sure you have installed @typescript-eslint/parser and eslint-import-resolver-typescript which are used in the following configuration.

{
  "extends": [
    "eslint:recommended",
    "plugin:import/recommended",
// the following lines do the trick
    "plugin:import/typescript",
  ],
  "settings": {
    "import/resolver": {
      // You will also need to install and configure the TypeScript resolver
      // See also https://github.com/import-js/eslint-import-resolver-typescript#configuration
      "typescript": true,
      "node": true,
    },
  },
}

Resolvers

With the advent of module bundlers and the current state of modules and module syntax specs, it's not always obvious where import x from 'module' should look to find the file behind module.

Up through v0.10ish, this plugin has directly used substack's resolve plugin, which implements Node's import behavior. This works pretty well in most cases.

However, webpack allows a number of things in import module source strings that Node does not, such as loaders (import 'file!./whatever') and a number of aliasing schemes, such as externals: mapping a module id to a global name at runtime (allowing some modules to be included more traditionally via script tags).

In the interest of supporting both of these, v0.11 introduces resolvers.

Currently Node and webpack resolution have been implemented, but the resolvers are just npm packages, so third party packages are supported (and encouraged!).

You can reference resolvers in several ways (in order of precedence):

  • as a conventional eslint-import-resolver name, like eslint-import-resolver-foo:

    // .eslintrc
{
"settings": {
 // uses 'eslint-import-resolver-foo':
 "import/resolver": "foo",
},
}
# .eslintrc.yml
settings:
  # uses 'eslint-import-resolver-foo':
  import/resolver: foo
// .eslintrc.js
module.exports = {
  settings: {
    'import/resolver': {
      foo: { someConfig: value }
    }
  }
}
  • with a full npm module name, like my-awesome-npm-module:
// .eslintrc
{
  "settings": {
    "import/resolver": "my-awesome-npm-module",
  },
}
# .eslintrc.yml
settings:
  import/resolver: 'my-awesome-npm-module'
// .eslintrc.js
module.exports = {
  settings: {
    'import/resolver': {
      'my-awesome-npm-module': { someConfig: value }
    }
  }
}
  • with a filesystem path to resolver, defined in this example as a computed property name:
// .eslintrc.js
module.exports = {
  settings: {
    'import/resolver': {
      [path.resolve('../../../my-resolver')]: { someConfig: value }
    }
  }
}

Relative paths will be resolved relative to the source's nearest package.json or the process's current working directory if no package.json is found.

If you are interesting in writing a resolver, see the spec for more details.

Settings

You may set the following settings in your .eslintrc:

import/extensions

A list of file extensions that will be parsed as modules and inspected for exports.

This defaults to ['.js'], unless you are using the react shared config, in which case it is specified as ['.js', '.jsx']. Despite the default, if you are using TypeScript (without the plugin:import/typescript config described above) you must specify the new extensions (.ts, and also .tsx if using React).

"settings": {
  "import/extensions": [
    ".js",
    ".jsx"
  ]
}

If you require more granular extension definitions, you can use:

"settings": {
  "import/resolver": {
    "node": {
      "extensions": [
        ".js",
        ".jsx"
      ]
    }
  }
}

Note that this is different from (and likely a subset of) any import/resolver extensions settings, which may include .json, .coffee, etc. which will still factor into the no-unresolved rule.

Also, the following import/ignore patterns will overrule this list.

import/ignore

A list of regex strings that, if matched by a path, will not report the matching module if no exports are found. In practice, this means rules other than no-unresolved will not report on any imports with (absolute filesystem) paths matching this pattern.

no-unresolved has its own ignore setting.

{
  "settings": {
    "import/ignore": [
      "\.coffee$", // fraught with parse errors
      "\.(scss|less|css)$", // can't parse unprocessed CSS modules, either
    ],
  },
}

import/core-modules

An array of additional modules to consider as "core" modules--modules that should be considered resolved but have no path on the filesystem. Your resolver may already define some of these (for example, the Node resolver knows about fs and path), so you need not redefine those.

For example, Electron exposes an electron module:

import 'electron'  // without extra config, will be flagged as unresolved!

that would otherwise be unresolved. To avoid this, you may provide electron as a core module:

// .eslintrc
{
  "settings": {
    "import/core-modules": ["electron"],
  },
}

In Electron's specific case, there is a shared config named electron that specifies this for you.

Contribution of more such shared configs for other platforms are welcome!

import/external-module-folders

An array of folders. Resolved modules only from those folders will be considered as "external". By default - ["node_modules"]. Makes sense if you have configured your path or webpack to handle your internal paths differently and want to consider modules from some folders, for example bower_components or jspm_modules, as "external".

This option is also useful in a monorepo setup: list here all directories that contain monorepo's packages and they will be treated as external ones no matter which resolver is used.

If you are using yarn PnP as your package manager, add the .yarn folder and all your installed dependencies will be considered as external, instead of internal.

Each item in this array is either a folder's name, its subpath, or its absolute prefix path:

  • jspm_modules will match any file or folder named jspm_modules or which has a direct or non-direct parent named jspm_modules, e.g. /home/me/project/jspm_modules or /home/me/project/jspm_modules/some-pkg/index.js.

  • packages/core will match any path that contains these two segments, for example /home/me/project/packages/core/src/utils.js.

  • /home/me/project/packages will only match files and directories inside this directory, and the directory itself.

Please note that incomplete names are not allowed here so components won't match bower_components and packages/ui won't match packages/ui-utils (but will match packages/ui/utils).

import/parsers

A map from parsers to file extension arrays. If a file extension is matched, the dependency parser will require and use the map key as the parser instead of the configured ESLint parser. This is useful if you're inter-op-ing with TypeScript directly using webpack, for example:

// .eslintrc
{
  "settings": {
    "import/parsers": {
      "@typescript-eslint/parser": [".ts", ".tsx"],
    },
  },
}

In this case, @typescript-eslint/parser must be installed and require-able from the running eslint module's location (i.e., install it as a peer of ESLint).

This is currently only tested with @typescript-eslint/parser (and its predecessor, typescript-eslint-parser) but should theoretically work with any moderately ESTree-compliant parser.

It's difficult to say how well various plugin features will be supported, too, depending on how far down the rabbit hole goes. Submit an issue if you find strange behavior beyond here, but steel your heart against the likely outcome of closing with wontfix.

import/resolver

See resolvers.

import/cache

Settings for cache behavior. Memoization is used at various levels to avoid the copious amount of fs.statSync/module parse calls required to correctly report errors.

For normal eslint console runs, the cache lifetime is irrelevant, as we can strongly assume that files should not be changing during the lifetime of the linter process (and thus, the cache in memory)

For long-lasting processes, like eslint_d or eslint-loader, however, it's important that there be some notion of staleness.

If you never use eslint_d or eslint-loader, you may set the cache lifetime to Infinity and everything should be fine:

// .eslintrc
{
  "settings": {
    "import/cache": {
      "lifetime": "∞", // or Infinity, in a JS config
    },
  },
}

Otherwise, set some integer, and cache entries will be evicted after that many seconds have elapsed:

// .eslintrc
{
  "settings": {
    "import/cache": {
      "lifetime": 5, // 30 is the default
    },
  },
}

import/internal-regex

A regex for packages should be treated as internal. Useful when you are utilizing a monorepo setup or developing a set of packages that depend on each other.

By default, any package referenced from import/external-module-folders will be considered as "external", including packages in a monorepo like yarn workspace or lerna environment. If you want to mark these packages as "internal" this will be useful.

For example, if your packages in a monorepo are all in @scope, you can configure import/internal-regex like this

// .eslintrc
{
  "settings": {
    "import/internal-regex": "^@scope/",
  },
}

SublimeLinter-eslint

SublimeLinter-eslint introduced a change to support .eslintignore files which altered the way file paths are passed to ESLint when linting during editing. This change sends a relative path instead of the absolute path to the file (as ESLint normally provides), which can make it impossible for this plugin to resolve dependencies on the filesystem.

This workaround should no longer be necessary with the release of ESLint 2.0, when .eslintignore will be updated to work more like a .gitignore, which should support proper ignoring of absolute paths via --stdin-filename.

In the meantime, see roadhump/SublimeLinter-eslint#58 for more details and discussion, but essentially, you may find you need to add the following SublimeLinter config to your Sublime project file:

{
    "folders":
    [
        {
            "path": "code"
        }
    ],
    "SublimeLinter":
    {
        "linters":
        {
            "eslint":
            {
                "chdir": "${project}/code"
            }
        }
    }
}

Note that ${project}/code matches the code provided at folders[0].path.

The purpose of the chdir setting, in this case, is to set the working directory from which ESLint is executed to be the same as the directory on which SublimeLinter-eslint bases the relative path it provides.

See the SublimeLinter docs on chdir for more information, in case this does not work with your project.

If you are not using .eslintignore, or don't have a Sublime project file, you can also do the following via a .sublimelinterrc file in some ancestor directory of your code:

{
  "linters": {
    "eslint": {
      "args": ["--stdin-filename", "@"]
    }
  }
}

I also found that I needed to set rc_search_limit to null, which removes the file hierarchy search limit when looking up the directory tree for .sublimelinterrc:

In Package Settings / SublimeLinter / User Settings:

{
  "user": {
    "rc_search_limit": null
  }
}

I believe this defaults to 3, so you may not need to alter it depending on your project folder max depth.

changelog

Change Log

All notable changes to this project will be documented in this file. This project adheres to Semantic Versioning. This change log adheres to standards from Keep a CHANGELOG.

Unreleased

2.31.0 - 2024-10-03

Added

Fixed

Changed

2.30.0 - 2024-09-02

Added

Fixed

Changed

  • [Docs] no-extraneous-dependencies: Make glob pattern description more explicit (#2944, thanks @mulztob)
  • no-unused-modules: add console message to help debug #2866
  • [Refactor] ExportMap: make procedures static instead of monkeypatching exportmap (#2982, thanks @soryy708)
  • [Refactor] ExportMap: separate ExportMap instance from its builder logic (#2985, thanks @soryy708)
  • [Docs] order: Add a quick note on how unbound imports and --fix (#2640, thanks @minervabot)
  • [Tests] appveyor -> GHA (run tests on Windows in both pwsh and WSL + Ubuntu) (#2987, thanks @joeyguerra)
  • [actions] migrate OSX tests to GHA (ljharb#37, thanks @aks-)
  • [Refactor] exportMapBuilder: avoid hoisting (#2989, thanks @soryy708)
  • [Refactor] ExportMap: extract "builder" logic to separate files (#2991, thanks @soryy708)
  • [Docs] order: update the description of the pathGroupsExcludedImportTypes option (#3036, thanks @liby)
  • [readme] Clarify how to install the plugin (#2993, thanks @jwbth)

2.29.1 - 2023-12-14

Fixed

2.29.0 - 2023-10-22

Added

2.28.1 - 2023-08-18

Fixed

Changed

  • [Docs] remove duplicate fixable notices in docs (#2850, thanks @bmish)

2.28.0 - 2023-07-27

Fixed

Changed

2.27.5 - 2023-01-16

Fixed

2.27.4 - 2023-01-11

Fixed

  • semver should be a prod dep (#2668)

2.27.3 - 2023-01-11

Fixed

2.27.2 - 2023-01-11

Fixed

2.27.1 - 2023-01-11

Fixed

2.27.0 - 2023-01-11

Added

Fixed

Changed

2.26.0 - 2022-04-05

Added

Fixed

Changed

2.25.4 - 2022-01-02

Fixed

  • importType: avoid crashing on a non-string' (#2305, thanks @ljharb)
  • first: prevent crash when parsing angular templates (#2210, thanks @ljharb)
  • importType: properly resolve @/*-aliased imports as internal (#2334, thanks @ombene)
  • named/ExportMap: handle named imports from CJS modules that use dynamic import (#2341, thanks @ludofischer)

Changed

  • [no-default-import]: report on the token "default" instead of the entire node (#2299, thanks @pmcelhaney)
  • [Docs] order: Remove duplicate mention of default (#2280, thanks @johnthagen)
  • [Deps] update eslint-module-utils

2.25.3 - 2021-11-09

Fixed

Changed

2.25.2 - 2021-10-12

Fixed

  • [Deps] update eslint-module-utils for real this time (#2255, thanks @ljharb)

2.25.1 - 2021-10-11

Fixed

  • [Deps] update eslint-module-utils

2.25.0 - 2021-10-11

Added

Fixed

Changed

2.24.2 - 2021-08-24

Fixed

2.24.1 - 2021-08-19

Fixed

Changed

2.24.0 - 2021-08-08

Added

Fixed

Changed

2.23.4 - 2021-05-29

Fixed

2.23.3 - 2021-05-21

Fixed

Changed

2.23.2 - 2021-05-15

Changed

  • [meta] add safe-publish-latest; use prepublishOnly script for npm 7+

2.23.1 - 2021-05-14

Fixed

2.23.0 - 2021-05-13

Added

Fixed

Changed

2.22.1 - 2020-09-27

Fixed

Changed

2.22.0 - 2020-06-26

Added

Fixed

Changed

2.21.2 - 2020-06-09

Fixed

2.21.1 - 2020-06-07

Fixed

  • TypeScript: [import/named]: avoid requiring typescript when not using TS (#1805, thanks @ljharb)

2.21.0 - 2020-06-07

Added

Fixed

Changed

[2.20.2] - 2020-03-28

Fixed

2.20.1 - 2020-02-01

Fixed

Changed

2.20.0 - 2020-01-10

Added

  • order: added caseInsensitive as an additional option to alphabetize (#1586, thanks @dbrewer5)
  • no-restricted-paths: New except option per zone, allowing exceptions to be defined for a restricted zone (#1238, thanks @rsolomon)
  • order: add option pathGroupsExcludedImportTypes to allow ordering of external import types (#1565, thanks @Mairu)

Fixed

Docs

2.19.1 - 2019-12-08

Fixed

2.19.0 - 2019-12-08

Added

Fixed

Docs

Changed

2.18.2 - 2019-07-19

Fixed

2.18.1 - 2019-07-18

Fixed

Refactors

2.18.0 - 2019-06-24

Added

Fixed

Docs

2.17.3 - 2019-05-23

Fixed

Docs

2.17.2 - 2019-04-16

Fixed

2.17.1 - 2019-04-13

Fixed

  • require v2.4 of eslint-module-utils (#1322)

2.17.0 - 2019-04-13

Added

Fixed

Docs

Tests

2.16.0 - 2019-01-29

Added

Fixed

2.15.0 - 2019-01-22

Added

Fixed

2.14.0 - 2018-08-13

Added

Fixed

Refactors

  • add explicit support for RestElement alongside ExperimentalRestProperty (thanks @ljharb)

2.13.0 - 2018-06-24

Added

Fixed

  • namespace rule: ensure it works in eslint 5/ecmaVersion 2018 (thanks @ljharb)

2.12.0 - 2018-05-17

Added

2.11.0 - 2018-04-09

Added

Fixed

2.10.0 - 2018-03-29

Added

2.9.0 - 2018-02-21

Added

2.8.0 - 2017-10-18

Added

Changed

  • Case-sensitivity checking ignores working directory and ancestors. (#720 + #858, thanks @laysent)

Fixed

2.7.0 - 2017-07-06

Changed

2.6.1 - 2017-06-29

Fixed

  • update bundled node resolver dependency to latest version

2.6.0 - 2017-06-23

Changed

  • update tests / peerDeps for ESLint 4.0 compatibility (#871, thanks @mastilver)
  • memo-parser updated to require filePath on parser options as it melts down if it's not there, now that this plugin always provides it. (see #863)

2.5.0 - 2017-06-22

Re-releasing v2.4.0 after discovering that the memory leak is isolated to the memo-parser, which is more or less experimental anyway.

Added

2.4.0 - 2017-06-02 [YANKED]

Yanked due to critical issue in eslint-module-utils with cache key resulting from #839.

Added

2.3.0 - 2017-05-18

Added

Changed

Fixed

  • attempt to fix crash in no-mutable-exports. (#660)
  • "default is a reserved keyword" in no-maned-default tests by locking down babylon to 6.15.0 (#756, thanks @gmathieu)
  • support scoped modules containing non word characters

2.2.0 - 2016-11-07

Fixed

  • Corrected a few gaffs in the auto-ignore logic to fix major performance issues with projects that did not explicitly ignore node_modules. (#654)
  • import/ignore setting was only being respected if the ignored module didn't start with an import or export JS statement
  • prefer-default-export: fixed crash on export extensions (#653)

2.1.0 - 2016-11-02

Added

Fixed

2.0.1 - 2016-10-06

Fixed

  • Fixed code that relied on removed dependencies. (#604)

2.0.0! - 2016-09-30

Added

  • unambiguous rule: report modules that are not unambiguously ES modules.
  • recommended shared config. Roughly errors and warnings mixed together, with some parserOptions in the mix. (#402)
  • react shared config: added jsx: true to parserOptions.ecmaFeatures.
  • Added no-webpack-loader-syntax rule: forbid custom Webpack loader syntax in imports. (#586, thanks @fson!)
  • Add option newlines-between: "ignore" to order (#519)
  • Added no-unassigned-import rule (#529)

Breaking

Changed

  • imports-first is renamed to first. imports-first alias will continue to exist, but may be removed in a future major release.
  • Case-sensitivity: now specifically (and optionally) reported by no-unresolved. Other rules will ignore case-mismatches on paths on case-insensitive filesystems. (#311)

Fixed

1.16.0 - 2016-09-22

Added

Fixed

1.15.0 - 2016-09-12

Added

Fixed

1.14.0 - 2016-08-22

Added

  • import/parsers setting: parse some dependencies (i.e. TypeScript!) with a different parser than the ESLint-configured parser. (#503)

Fixed

  • namespace exception for get property from namespace import, which are re-export from commonjs module (#499 fixes #416, thanks @wKich)

1.13.0 - 2016-08-11

Added

  • allowComputed option for namespace rule. If set to true, won't report computed member references to namespaces. (see #456)

Changed

Fixed

1.12.0 - 2016-07-26

Added

1.11.1 - 2016-07-20

Fixed

1.11.0 - 2016-07-17

Added

Fixed

1.10.3 - 2016-07-08

Fixed

  • removing Symbol dependencies (i.e. for-of loops) due to Node 0.10 polyfill issue (see #415). Should not make any discernible semantic difference.

1.10.2 - 2016-07-04

Fixed

  • Something horrible happened during npm prepublish of 1.10.1. Several rm -rf node_modules && npm i and gulp clean && npm prepublishs later, it is rebuilt and republished as 1.10.2. Thanks @rhettlivingston for noticing and reporting!

1.10.1 - 2016-07-02 [YANKED]

Added

  • Officially support ESLint 3.x. (peerDependencies updated to 2.x - 3.x)

1.10.0 - 2016-06-30

Added

Fixed

  • Fixed crash with newline-after-import related to the use of switch cases. (fixes #386, thanks @ljharb for reporting) (#395)

1.9.2 - 2016-06-21

Fixed

1.9.1 - 2016-06-16

Fixed

  • Reordered precedence for loading resolvers. (#373)

1.9.0 - 2016-06-10

Added

Fixed

1.8.1 - 2016-05-23

Fixed

1.8.0 - 2016-05-11

Added

Fixed

1.7.0 - 2016-05-06

Added

Fixed

  • extensions: fallback to source path for extension enforcement if imported module is not resolved. Also, never report for builtins (i.e. path). (#296)

1.6.1 - 2016-04-28

Fixed

1.6.0 - 2016-04-25

Added

Changed

Fixed

  • named now properly ignores the source module if a name is re-exported from an ignored file (i.e. node_modules). Also improved the reported error. (thanks to @jimbolla for reporting)
  • no-named-as-default-member had a crash on destructuring in loops (thanks for heads up from @lemonmade)

1.5.0 - 2016-04-18

Added

Changed

  • Rearranged rule groups in README in preparation for more style guide rules

Removed

  • support for Node 0.10, via es6-* ponyfills. Using native Map/Set/Symbol.

1.4.0 - 2016-03-25

Added

  • Resolver plugin interface v2: more explicit response format that more clearly covers the found-but-core-module case, where there is no path. Still backwards-compatible with the original version of the resolver spec.
  • Resolver documentation

Changed

  • using package.json/files instead of .npmignore for package file inclusion (#228, thanks @mathieudutour)
  • using es6-* ponyfills instead of babel-runtime

1.3.0 - 2016-03-20

Major perf improvements. Between parsing only once and ignoring gigantic, non-module node_modules, there is very little added time.

My test project takes 17s to lint completely, down from 55s, when using the memoizing parser, and takes only 27s with naked babel-eslint (thus, reparsing local modules).

Added

  • This change log (#216)
  • Experimental memoizing parser

Fixed

  • Huge reduction in execution time by only ignoring import/ignore setting if something that looks like an export is detected in the module content.

1.2.0 - 2016-03-19

Thanks @lencioni for identifying a huge amount of rework in resolve and kicking off a bunch of memoization.

I'm seeing 62% improvement over my normal test codebase when executing only no-unresolved in isolation, and ~35% total reduction in lint time.

Changed

1.1.0 - 2016-03-15

Added

  • Added an ignore option to no-unresolved for those pesky files that no resolver can find. (still prefer enhancing the Webpack and Node resolvers to using it, though). See #89 for details.

1.0.4 - 2016-03-11

Changed

Fixed

  • don't crash on self references (#210)
  • correct cache behavior in eslint_d for deep namespaces (#200)

1.0.3 - 2016-02-26

Changed

  • no-deprecated follows deep namespaces (#191)

Fixed

  • namespace no longer flags modules with only a default export as having no names. (ns.default is valid ES6)

1.0.2 - 2016-02-26

Fixed

  • don't parse imports with no specifiers (#192)

1.0.1 - 2016-02-25

Fixed

  • export stage-0 shared config
  • documented no-deprecated
  • deep namespaces are traversed regardless of how they get imported (#189)

1.0.0 - 2016-02-24

Added

  • no-deprecated: WIP rule to let you know at lint time if you're using deprecated functions, constants, classes, or modules.

Changed

1.0.0-beta.0 - 2016-02-13

Changed

  • support for (only) ESLint 2.x
  • no longer needs/refers to import/parser or import/parse-options. Instead, ESLint provides the configured parser + options to the rules, and they use that to parse dependencies.

Removed

  • babylon as default import parser (see Breaking)

0.13.0 - 2016-02-08

Added

Removed

  • Removed vestigial no-require rule. no-commonjs is more complete.

0.12.2 - 2016-02-06 [YANKED]

Unpublished from npm and re-released as 0.13.0. See #170.

0.12.1 - 2015-12-17

Changed

  • Broke docs for rules out into individual files.

0.12.0 - 2015-12-14

Changed

  • Ignore import/ignore setting if exports are actually found in the parsed module. Does this to support use of jsnext:main in node_modules without the pain of managing an allow list or a nuanced deny list.

0.11.0 - 2015-11-27

Added

  • Resolver plugins. Now the linter can read Webpack config, properly follow aliases and ignore externals, dismisses inline loaders, etc. etc.!

Earlier releases (0.10.1 and younger)

See GitHub release notes for info on changes for earlier releases.