eslint plugin import
v2.31.0
Este complemento tiene la intención de admitir la pelusa de la sintaxis de importación/exportación ES2015+ (ES6+), y evitar problemas con la falta de ortografía de las rutas de archivos y los nombres de importación. Toda la bondad que pretende proporcionar la sintaxis del módulo estático ES2015+, marcada en su editor.
Si está utilizando esto con Sublime : consulte la sección inferior para obtener información importante.
Configuraciones habilitadas en.
Configuraciones deshabilitadas en.
❗ Establecer en la configuración errors .
☑️ Establecer en la configuración recommended .
⌨️ Establecer en la configuración typescript .
? Establecido en la configuración warnings .
? Forzable automáticamente por la opción CLI --fix .
Manualmente reparable por las sugerencias del editor.
Desapercibido.
| Nombre | Descripción | ? | |||||
|---|---|---|---|---|---|---|---|
| exportar | Prohibir cualquier exportación inválida, es decir, reexportar el mismo nombre. | ❗️ | |||||
| no depredado | Prohibir los nombres importados marcados con la etiqueta de documentación @deprecated . | ||||||
| bloqueos sin nombre vacío | Prohibir los bloques de importación con nombre vacío. | ? | |||||
| sin dependencias | Prohibir el uso de paquetes extraños. | ||||||
| exportadoras no mutables | Prohibir el uso de exportaciones mutables con var o let . | ||||||
| no nombrado como deformento | Prohibir el uso del nombre exportado como identificador de exportación predeterminada. | ☑️? | |||||
| no nombrado como miembro | Prohibir el uso del nombre exportado como propiedad de la exportación predeterminada. | ☑️? | |||||
| Módulos sin usar | Prohibir módulos sin exportaciones o exportaciones sin hacer coincidir la importación en otro módulo. |
| Nombre | Descripción | ? | |||||
|---|---|---|---|---|---|---|---|
| no-amd | Prohibir que AMD require y define llamadas. | ||||||
| sin comonjs | Prohibir CommonJs require llamadas y module.exports Exports o exports.* . | ||||||
| sin importación-module-exports | Prohibir las declaraciones de importación con CommonJS Module.Exports. | ? | |||||
| no-nodejs-módulos | Forbid node.js módulos construidos. | ||||||
| inequívoco | Prohibir el objetivo de análisis potencialmente ambiguo ( script vs. module ). |
| Nombre | Descripción | ? | |||||
|---|---|---|---|---|---|---|---|
| por defecto | Asegúrese de que esté presente una exportación predeterminada, dada una importación predeterminada. | ❗️ | |||||
| imponer el nodo-protocolo | Haga cumplir utilizando u omitiendo, el node: protocolo al importar nodo.js builtin módulos. | ? | |||||
| nombrado | Asegúrese de que las importaciones nombradas correspondan a una exportación con nombre en el archivo remoto. | ❗️ | ⌨️ | ||||
| espacio de nombres | Asegúrese de que los espacios de nombres importados contengan propiedades desferenciadas a medida que estén desactivadas. | ❗️ | |||||
| no-absoluta | Prohibir la importación de módulos utilizando rutas absolutas. | ? | |||||
| sin ciclo | Prohibir que un módulo importe un módulo con una ruta de dependencia de regreso a sí misma. | ||||||
| no dinámico | Prohibir las llamadas require() con expresiones. | ||||||
| sin módulos | Prohibir la importación de los submódulos de otros módulos. | ||||||
| Trenos sin relativos | Prohibir la importación de paquetes a través de rutas relativas. | ? | |||||
| No-Relativo-Importación | Prohibir los módulos de importación de los directorios de los padres. | ||||||
| no restringidos | Haga cumplir qué archivos se pueden importar en una carpeta determinada. | ||||||
| No-Self-Import | Prohibir que un módulo se importe. | ||||||
| no sin resuelto | Asegúrese de que las importaciones apunten a un archivo/módulo que se pueda resolver. | ❗️ | |||||
| segmentos no inútiles | Prohibir segmentos de ruta innecesarios en la importación y requieren declaraciones. | ? | |||||
| sin-webpack-carner-syntax | Prohibir la sintaxis del cargador webpack en las importaciones. |
| Nombre | Descripción | ? | |||||
|---|---|---|---|---|---|---|---|
| estilo específico de tipo consistente | Haga cumplir o prohíbe el uso de marcadores de solo tipo en línea para las importaciones con nombre. | ? | |||||
| Dynamic-Import-chunkname | Haga cumplir un comentario principal con WebPackChunkname para importaciones dinámicas. | ||||||
| exportación | Asegúrese de que todas las exportaciones aparezcan después de otras declaraciones. | ||||||
| extensiones | Asegure el uso constante de la extensión del archivo dentro de la ruta de importación. | ||||||
| primero | Asegúrese de que todas las importaciones aparezcan ante otras declaraciones. | ? | |||||
| exportador de grupo | Preferir las exportaciones con nombre para agruparse en una sola declaración de exportación | ||||||
| importaciones primero | Reemplazado por import/first . | ? | |||||
| dependencias máximas | Haga cumplir el número máximo de dependencias que puede tener un módulo. | ||||||
| nueva línea después de importación | Haga cumplir una nueva línea después de las declaraciones de importación. | ? | |||||
| no anónimo-default-export | Prohibir los valores anónimos como exportaciones predeterminadas. | ||||||
| sin defecto-exportación | Prohibir las exportaciones predeterminadas. | ||||||
| no duplicados | Prohibir la importación repetida del mismo módulo en múltiples lugares. | ☑️? | ? | ||||
| no llamado default | Prohibir las exportaciones predeterminadas nombradas. | ||||||
| No-Named-Export | Prohibir las exportaciones nombradas. | ||||||
| sin nuguaces | Prohibir las importaciones del espacio de nombres (también conocido como "comodín" * ). | ? | |||||
| no uniforme | Prohibir las importaciones no asignadas | ||||||
| orden | Hacer cumplir una convención en la orden de importación del módulo. | ? | |||||
| preferir-default-export | Prefiera una exportación predeterminada si el módulo exporta un solo nombre o nombres múltiples. |
eslint-plugin-import para EnterpriseDisponible como parte de la suscripción de TidElift.
Los mantenedores de eslint-plugin-import y miles de otros paquetes están trabajando con TidElift para ofrecer soporte y mantenimiento comerciales para las dependencias de código abierto que utiliza para construir sus aplicaciones. Ahorre tiempo, reduzca el riesgo y mejore la salud del código, al tiempo que paga a los mantenedores de las dependencias exactas que usa. Aprende más.
# inside your project's working tree
npm install eslint-plugin-import --save-dev.eslintrc ) Todas las reglas están apagadas por defecto. Sin embargo, puede extender una de las configuraciones preestablecidas, o configurarlas manualmente en su .eslintrc.(yml|json|js) .
{
"extends" : [
"eslint:recommended" ,
"plugin:import/recommended" ,
] ,
} {
"rules" : {
"import/no-unresolved" : [ "error" , { "commonjs" : true , "amd" : true } ] ,
"import/named" : "error" ,
"import/namespace" : "error" ,
"import/default" : "error" ,
"import/export" : "error" ,
// etc...
} ,
} ,eslint.config.js ) Todas las reglas están apagadas por defecto. Sin embargo, puede configurarlos manualmente en su eslint.config.(js|cjs|mjs) , o extender una de las configuraciones preestablecidas:
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' ,
} ,
} ,
] ; Puede usar el siguiente fragmento o ensamblar su propia configuración utilizando la configuración granular que se describe a continuación.
Asegúrese de haber instalado @typescript-eslint/parser y eslint-import-resolver-typescript que se utilizan en la siguiente configuración.
{
"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 ,
} ,
} ,
}config() en typescript-eslint Si está utilizando el método config de typescript-eslint , asegúrese de que el flatConfig esté incluido dentro de la matriz extends .
import tseslint from 'typescript-eslint' ;
import importPlugin from 'eslint-plugin-import' ;
import js from '@eslint/js' ;
export default tseslint . config (
js . configs . recommended ,
// other configs...
{
files : [ '**/*.{ts,tsx}' ] ,
extends : [ importPlugin . flatConfigs . recommended ] ,
// other configs...
}
) ; Con el advenimiento de los agrupadores de módulos y el estado actual de los módulos y las especificaciones de sintaxis del módulo, no siempre es obvio donde import x from 'module' debería buscar el archivo detrás module .
A través de V0.10ish, este complemento ha utilizado directamente el complemento resolve de Susmack, lo que implementa el comportamiento de importación del nodo. Esto funciona bastante bien en la mayoría de los casos.
Sin embargo, Webpack permite una serie de cosas en las cadenas de origen del módulo de importación que el nodo no, como los cargadores ( import 'file!./whatever' ) y una serie de esquemas de alias, como externals : asignar una ID de módulo a un nombre global en tiempo de ejecución (permitiendo que algunos módulos se incluyan más tradicionalmente a través de etiquetas de secuencia de comandos).
En aras de apoyar a ambos, V0.11 introduce resueltos.
Actualmente se han implementado la resolución de Node y Webpack, pero los solucionadores son solo paquetes de NPM, por lo que los paquetes de terceros son compatibles (¡y alentados!).
Puede hacer referencia a los resolcadores de varias maneras (en orden de precedencia):
eslint-import-resolver , como 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 }
}
}
}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 }
}
}
}computed property : // .eslintrc.js
module . exports = {
settings : {
'import/resolver' : {
[ path . resolve ( '../../../my-resolver' ) ] : { someConfig : value }
}
}
} Las rutas relativas se resolverán en relación con el package.json más cercano de la fuente. Json o el directorio de trabajo actual del proceso si no se encuentra ningún package.json .
Si le interesa escribir un resolución, consulte la especificación para obtener más detalles.
Puede establecer la siguiente configuración en su .eslintrc :
import/extensions Una lista de extensiones de archivos que se analizarán como módulos e inspeccionados para export .
Este valor predeterminado a ['.js'] , a menos que esté utilizando la configuración compartida react , en cuyo caso se especifica como ['.js', '.jsx'] . A pesar del valor predeterminado, si está utilizando TypeScript (sin el plugin:import/typescript Config descrito anteriormente) debe especificar las nuevas extensiones ( .ts y también .tsx si usa React).
"settings" : {
"import/extensions" : [
".js" ,
".jsx"
]
}Si necesita más definiciones de extensión granular, puede usar:
"settings" : {
"import/resolver" : {
"node" : {
"extensions" : [
".js" ,
".jsx"
]
}
}
} Tenga en cuenta que esto es diferente de (y probablemente un subconjunto de) cualquier configuración de extensiones import/resolver , que puede incluir .json , .coffee , etc. que aún tendrá en cuenta la regla no-unresolved .
Además, los siguientes patrones import/ignore anularán esta lista.
import/ignore Una lista de cadenas Regex que, si coinciden con una ruta, no informará el módulo de coincidencia si no se encuentran export . En la práctica, esto significa que las reglas que no sean no-unresolved no informarán sobre ninguna import con rutas (sistema de archivos absoluto) que coincidan con este patrón.
no-unresolved tiene su propia configuración ignore .
{
"settings" : {
"import/ignore" : [
".coffee$" , // fraught with parse errors
".(scss|less|css)$" , // can't parse unprocessed CSS modules, either
] ,
} ,
}import/core-modules Una variedad de módulos adicionales a considerar como módulos "centrales", módulos que deben considerarse resueltos pero que no tienen ruta en el sistema de archivos. Su resolución ya puede definir algunos de estos (por ejemplo, el resolución de nodos sabe sobre fs y path ), por lo que no necesita redefinirlos.
Por ejemplo, Electron expone un módulo electron :
import 'electron' // without extra config, will be flagged as unresolved! Eso de otro modo no sería resuelto. Para evitar esto, puede proporcionar electron como módulo de núcleo:
// .eslintrc
{
"settings" : {
"import/core-modules" : [ "electron" ] ,
} ,
} En el caso específico de Electron, hay una configuración compartida llamada electron que especifica esto para usted.
¡La contribución de más configuraciones compartidas para otras plataformas es bienvenida!
import/external-module-folders Una variedad de carpetas. Los módulos resueltos solo de esas carpetas se considerarán como "externos". Por defecto - ["node_modules"] . Tiene sentido si ha configurado su ruta o paquete web para manejar sus rutas internas de manera diferente y desea considerar módulos de algunas carpetas, por ejemplo, bower_components o jspm_modules , como "externo".
Esta opción también es útil en una configuración de Monorepo: Lista aquí todos los directorios que contienen los paquetes de Monorepo y serán tratados como externas sin importar qué resolución se use.
Si está utilizando yarn PNP como Administrador de paquetes, agregue la carpeta .yarn y todas sus dependencias instaladas se considerarán external , en lugar de internal .
Cada elemento en esta matriz es el nombre de una carpeta, su subpath o su ruta de prefijo absoluta:
jspm_modules coincidirá con cualquier archivo o carpeta llamada jspm_modules o que tenga un padre directo o no directo llamado jspm_modules , eg /home/me/project/jspm_modules o /home/me/project/jspm_modules/some-pkg/index.js .
packages/core coincidirá con cualquier ruta que contenga estos dos segmentos, por ejemplo /home/me/project/packages/core/src/utils.js .
/home/me/project/packages solo coincidirá con archivos y directorios dentro de este directorio, y el directorio en sí.
Tenga en cuenta que los nombres incompletos no están permitidos aquí para que components no coincidan con bower_components y packages/ui no coincidan con packages/ui-utils (pero coincidirán con packages/ui/utils ).
import/parsersUn mapa de analizadores a matrices de extensión de archivos. Si se combina una extensión de archivo, el analizador de dependencia requerirá y usará la tecla MAP como analizador en lugar del analizador de Eslint configurado. Esto es útil si se interpone con TypeScript directamente usando Webpack, por ejemplo:
// .eslintrc
{
"settings" : {
"import/parsers" : {
"@typescript-eslint/parser" : [ ".ts" , ".tsx" ] ,
} ,
} ,
} En este caso, se debe instalar y requerir la ubicación del módulo de eslint (es @typescript-eslint/parser , instálelo como un par de eslint).
Actualmente, esto solo se prueba con @typescript-eslint/parser (y su predecesor, typescript-eslint-parser ), pero debería funcionar teóricamente con cualquier analizador moderadamente que compleja.
Es difícil decir qué tan bien también serán compatibles con varias características del complemento, dependiendo de qué tan lejos llegue la madriguera del conejo. Envíe un problema si encuentra un comportamiento extraño más allá de aquí, pero acelera su corazón contra el probable resultado del cierre con wontfix .
import/resolverVer Resoluciones.
import/cache Configuración para el comportamiento de caché. La memorización se usa en varios niveles para evitar la gran cantidad de llamadas de análisis fs.statSync /Module requeridas para informar correctamente los errores.
Para las ejecuciones normales de la consola eslint , la vida útil de la memoria caché es irrelevante, ya que podemos suponer fuertemente que los archivos no deberían cambiar durante la vida útil del proceso del enlace (y por lo tanto, el caché en la memoria)
Sin embargo, para procesos duraderos, como eslint_d o eslint-loader , es importante que haya alguna noción de estancamiento.
Si nunca usa eslint_d o eslint-loader , puede establecer la vida útil de la caché en Infinity y todo debería estar bien:
// .eslintrc
{
"settings" : {
"import/cache" : {
"lifetime" : "∞" , // or Infinity, in a JS config
} ,
} ,
}De lo contrario, establezca algunos enteros, y las entradas de caché se desalijarán después de que hayan transcurrido muchos segundos:
// .eslintrc
{
"settings" : {
"import/cache" : {
"lifetime" : 5 , // 30 is the default
} ,
} ,
}import/internal-regexUna regex para los paquetes debe tratarse como interno. Útil cuando está utilizando una configuración de Monorepo o desarrollando un conjunto de paquetes que dependen unos de otros.
De manera predeterminada, cualquier paquete referenciado desde import/external-module-folders se considerará como "externo", incluidos los paquetes en un Monorepo como el espacio de trabajo de hilo o el entorno Lerna. Si desea marcar estos paquetes como "internos", esto será útil.
Por ejemplo, si sus paquetes en un Monorepo están todos en @scope , puede configurar import/internal-regex como este
// .eslintrc
{
"settings" : {
"import/internal-regex" : "^@scope/" ,
} ,
}import/node-versionUna cadena que representa la versión de Node.js que está utilizando. Un valor falsificado implicará la versión de Node.js con la que está ejecutando Eslint.
// .eslintrc
{
"settings" : {
"import/node-version" : "22.3.4" ,
} ,
} Sublimelinter-slint introdujo un cambio para admitir archivos .eslintignore que alteraron la forma en que las rutas de archivos se pasan a Eslint cuando se pelean durante la edición. Este cambio envía una ruta relativa en lugar de la ruta absoluta al archivo (como lo proporciona normalmente Eslint), lo que puede hacer que sea imposible que este complemento resuelva las dependencias en el sistema de archivos.
Esta solución ya no debería ser necesaria con el lanzamiento de Eslint 2.0, cuando .eslintignore se actualizará para trabajar más como un .gitignore , lo que debería admitir la ignoración adecuada de las rutas absolutas a través de --stdin-filename .
Mientras tanto, consulte Roadhump/Sublimelinter-Eslint#58 para obtener más detalles y discusión, pero esencialmente, es posible que deba agregar la siguiente configuración SublimeLinter a su archivo de proyecto sublime:
{
"folders" :
[
{
"path" : " code "
}
],
"SublimeLinter" :
{
"linters" :
{
"eslint" :
{
"chdir" : " ${project}/code "
}
}
}
} Tenga en cuenta que ${project}/code coincide con el code proporcionado en folders[0].path .
El propósito de la configuración chdir , en este caso, es establecer el directorio de trabajo desde el cual se ejecuta Eslint para que sea el mismo que el directorio en el que sublimelinter-lint basa la ruta relativa que proporciona.
Consulte los documentos de sublimelinter en chdir para obtener más información, en caso de que esto no funcione con su proyecto.
Si no está utilizando .eslintignore , o no tiene un archivo de proyecto sublime, también puede hacer lo siguiente a través de un archivo .sublimelinterrc en algún directorio de antepasados de su código:
{
"linters" : {
"eslint" : {
"args" : [ " --stdin-filename " , " @ " ]
}
}
} También descubrí que necesitaba establecer rc_search_limit en null , que elimina el límite de búsqueda de la jerarquía de archivos al buscar el árbol de directorio para .sublimelinterrc :
En configuración de paquete / sublimelinter / configuración de usuario:
{
"user" : {
"rc_search_limit" : null
}
} Creo que este valor predeterminado a 3 , por lo que es posible que no necesite alterarlo según la profundidad máxima de su carpeta de proyecto.
