consistent-type-specifier-style
default
dynamic-import-chunkname
webpackChunkName
. This helps in generating more predictable and identifiable chunk filenames during the build process, which is crucial for debugging and optimizing the load of scripts.webpackChunkName
for dynamic imports, the rule fosters better code documentation and readability. It makes it clear to developers working on the project which chunks correspond to which dynamic imports, facilitating easier maintenance and understanding of the codebase.webpackChunkName
through this rule can also assist in more effective cache management on the client-side. By having named chunks, it becomes easier to invalidate the cache for specific modules when they are updated, rather than forcing a download of the entire bundle again, thus optimizing bandwidth usage and update deployment.export
exports-last
extensions
first
group-exports
imports-first
import/first
.max-dependencies
named
import { namedExport } from 'module'
) and CommonJS require syntax with destructuring (const { namedExport } = require('module')
), making it versatile and applicable to a wide range of JavaScript projects with different module systems.namespace
allowComputed
), it aids in maintaining static analyzability of the code. Static analysis tools can more easily reason about the code’s behavior when it adheres to more predictable, static access patterns. This makes the codebase easier to optimize, refactor, and debug.newline-after-import
no-absolute-path
no-amd
require
and define
calls.require
and define
functions, which is important for projects that aim to maintain a modern JavaScript codebase.no-anonymous-default-export
no-commonjs
require
calls and module.exports
or exports.*
.import
and export
) over CommonJS syntax (require
, module.exports
, exports.*
), ensuring consistency and readability within the codebase. This can be particularly important in projects that aim to be compliant with modern JavaScript standards or those transitioning from CommonJS to ES modules.
no-cycle
no-default-export
no-deprecated
@deprecated
documentation tag.@deprecated
documentation tags. This ensures developers are alerted when they are relying on outdated parts of their dependencies that may be removed in future versions, thus encouraging the use of more current and supported features.
no-duplicates
no-dynamic-require
require()
calls with expressions.require()
calls are made with string literals, rather than expressions that evaluate at runtime. It makes the dependencies of a module easier to understand and analyze statically, which is essential for tooling and refactoring purposes.require()
calls, the rule can significantly mitigate the risk of accidentally introducing security vulnerabilities, such as Remote Code Execution (RCE) vulnerabilities, through manipulatable input that might dynamically determine which modules are imported.require()
calls allow for more efficient bundling and dead code elimination by build tools like Webpack, which can statically analyze the dependency graph. Dynamic requires, on the other hand, may prevent these optimizations, leading to larger bundle sizes and slower application startup times.no-empty-named-blocks
no-extraneous-dependencies
package.json
, which helps in avoiding runtime errors due to missing dependencies. When a package is imported but not defined in package.json
, it might work in a developer’s environment (due to the package being installed globally or as a part of another package) but fail in production or on another developer’s machine.no-import-module-exports
module.exports
with ES module import syntax within the same file, which could lead to confusion or errors during the build or runtime phase due to differing module resolution mechanisms.no-internal-modules
no-mutable-exports
var
or let
.no-named-as-default-member
no-named-as-default
no-named-default
import { default as ReactComponent } from 'react';
can be misleading as it looks like a named import but actually is a default import.import ReactComponent from 'react';
), rather than mimicking a named import syntax.no-named-export
no-namespace
*
) imports.no-nodejs-modules
no-relative-packages
no-relative-parent-imports
no-restricted-paths
no-self-import
no-unassigned-import
import/no-unassigned-import
specifically targets unassigned imports, which are imports that are pulled into the file but not assigned to a variable. This rule helps ensure that all imported modules are used within the code, promoting a cleaner and more readable codebase by eliminating unused code and potential side effects from unnecessary imports.
no-unresolved
no-unused-modules
no-useless-path-segments
no-webpack-loader-syntax
order
newlines-between
, pathGroupsExcludedImportTypes
, and alphabetization settings. This flexibility ensures that the rule can be adapted to various coding standards and preferences, promoting adherence without compromising on individual or team practices.prefer-default-export
unambiguous
script
vs. module
).