eslint-plugin-import

https://github.com/import-js/eslint-plugin-import/blob/v2.23.3/CHANGELOG.md#2233---2021-05-21

https://github.com/import-js/eslint-plugin-import/blob/v2.23.2/CHANGELOG.md#2232---2021-05-15

https://github.com/import-js/eslint-plugin-import/blob/aa8d566b288eb0fdce24f3a51f8a65cf520c2133/CHANGELOG.md#2231---2021-05-14

https://github.com/benmosher/eslint-plugin-import/blob/v2.23.0/CHANGELOG.md#2230---2021-05-13

https://github.com/benmosher/eslint-plugin-import/blob/v2.22.1/CHANGELOG.md#2221---2020-09-27

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

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

• added an ignore option to no-unresolved for those pesky files for which no resolver can find. (still prefer enhancing the Webpack and Node resolvers to using it, though)

1.0.2:

fix #192

1.0.3:
no-deprecated follows deep namespaces (#191)

1.0.4:
don't crash on self references (#210)
correct cache behavior in eslint_d for deep namespaces (#200)
respect hoisting for deep namespaces (namespace/no-deprecated) (#211)

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

• import/namespace: support deep namespaces #119 via #157
• import/no-deprecated: WIP rule to let you know at lint time if you're using deprecated functions, constants, classes, or modules.

From the beta 1.0 release notes:

Update, verified to work with ESLint 2.0.

"Breaking" changes from 0.13.0:

no longer needs/refers to import/parser or import/parse-options. instead, ESLint provided the configured parser + options to the rules, and they use that to parse dependencies.

Shouldn't hurt to leave it there, and I suspect 99.999% of installs have import/parser === parser.

This also means the plugin uses espree instead of babylon if no parser is configured. Wouldn't expect this to hurt in general, but it is a potentially breaking difference.

eslint-config-import is no longer supported. Instead, use the shared configs directly exported by the plugin. See the README for details.

Nothing groundbreaking, but import/parser has been a thorny issue for the whole life of the plugin, and I'm glad to finally be rid of it. 😅

bugfixes:

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

Update, verified to work with ESLint 2.0.

"Breaking" changes from 0.13.0:

• no longer needs/refers to import/parser or import/parse-options. instead, ESLint provided the configured parser + options to the rules, and they use that to parse dependencies.

  Shouldn't hurt to leave it there, and I suspect 99.999% of installs have import/parser === parser.

  This also means the plugin uses espree instead of babylon if no parser is configured. Wouldn't expect this to hurt in general, but it is a potentially breaking difference.

• eslint-config-import is no longer supported. Instead, use the shared configs directly exported by the plugin. See the README for details.

Nothing groundbreaking, but import/parser has been a thorny issue for the whole life of the plugin, and I'm glad to finally be rid of it. 😅

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

#166: allow aliases to contain separators. (thanks @nosnickid!)

no-commonjs and no-amd rules added. (thanks @xjamundx for donating code to get these going)

Moved rule details into separate files, so the README is shorter and does not distract from config settings (resolvers, import/parser, etc.).

No code changes, should be functionally identical to v0.12.0.

• Ignore import/ignore 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 a whitelist or a nuanced blacklist. May be removed pending how surprising/helpful it ends up being.

• support for absolute config paths (thanks @nosnickid! via #136)
• support for eslint-loader, by resolving relative paths. (thanks @xjamundx! via #138)
• support for array resolve.root, where TIL bower_components should live (not in moduleDirectories)

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

• cache correctness: should properly re-load changed files even in a long lived process (like a webpack dev server)
• fixed issue where inferring JSX parsing from ecmaFeatures.jsx was broken when ESLint froze the context and settings. My own fault... not very hygienic to mutate shared state in the first place.

Breaking: removed no-errors rule. Instead, each individual rule will report parse errors in the target imported file, if encountered.

#90: Added {commonjs: [bool], amd: [bool]} option object to no-unresolved. If set true, will attempt to resolve module paths for CommonJS require and AMD define + require in a limited set of cases. Not nearly so smart as Webpack, but smart enough to be useful. (hopefully.) Thanks @mctep for changing my mind on this. 😁

#94: Dependency parser will infer 'jsx' plugin if using default Babylon and jsx is asserted in the ecmaFeatures. Thanks @jameslnewell for bringing this up.

#88: un-smarted no-require. It will now report on all require statements, everywhere, regardless of target.