eslint plugin import

Eslint-Plugin-Import

Este plug -in pretende suportar o revestimento da sintaxe de importação/exportação ES2015+ (ES6+) e evitar problemas com erros de arquivo e nomes de importação. Toda a bondade que a sintaxe do módulo estático ES2015+ pretende fornecer, marcada no seu editor.

Se você estiver usando isso com sublime : consulte a seção inferior para obter informações importantes.

Regras

Configurações ativadas.
️ Configurações definidas para avisar.
Configurações desativadas em.
❗ Defina na configuração errors .
☑️ Defina na configuração recommended .
⌨️ Defina na configuração typescript .
? Definido na configuração warnings .
? Automaticamente fixável pela opção --fix CLI.
Manualmente fixável por sugestões do editor.
Descontinuado.

Avisos úteis

Nome	Descrição		️		?
exportar	Proibir quaisquer exportações inválidas, ou seja, reexportar o mesmo nome.	❗ ☑️
não depreciado	Proibir nomes importados marcados com a tag @deprecated Documentation.
Blocks sem nome	Proibir blocos de importação nomeados vazios.				?
sem dependências não exclusivas	Proibir o uso de pacotes estranhos.
Exportações sem grande porte	Proibir o uso de exportações mutáveis ​​com var ou let .
Não-nome-como-defasa	Proibir o uso do nome exportado como identificador da exportação padrão.		☑️?
NO NOMED-AS-MEMBER	Proibir o uso do nome exportado como propriedade da exportação padrão.		☑️?
Módulos não usados	Proibir módulos sem exportação ou exportações sem a importação correspondente em outro módulo.

Sistemas de módulo

Nome	Descrição		️		?
não-AMD	Proibir a AMD require e define chamadas.
No-Commonjs	Proibir o CommonJS require chamadas e module.exports ou exports.* .
No-Import-Module-Exports	Proibir declarações de importação com o Commonjs Module.Exports.				?
Módulos sem-nodeJs	Proibir módulos Node.js Buildin.
inequívoco	Proibir o objetivo de análise potencialmente ambíguo ( script vs. module ).

Análise estática

Nome	Descrição		️		?
padrão	Verifique se uma exportação padrão está presente, dada uma importação padrão.	❗ ☑️
aplicar-se-nó-protocolo-uso	Aplicar o uso ou omitir o node: protocolo ao importar módulos Node.js.				?
nomeado	Verifique se as importações nomeadas correspondem a uma exportação nomeada no arquivo remoto.	❗ ☑️		⌨️
espaço para nome	Certifique -se de que os espaços para nomes importados contenham propriedades dereferenciadas à medida que são desreferenciadas.	❗ ☑️
Não-absoluto-caminho	Proibir a importação de módulos usando caminhos absolutos.				?
sem ciclo	Proibir um módulo de importar um módulo com um caminho de dependência de volta para si mesmo.
No-diâmico-requisito	Proibir require() chamadas com expressões.
Módulos sem internal	Proibir a importação dos submódulos de outros módulos.
pacotes sem relatórios	Proíba pacotes de importação por meio de caminhos relativos.				?
Importações sem parentes-parentes	Proibir módulos de importação de diretórios de pais.
Paths sem restrições	Aplicar quais arquivos podem ser importados em uma determinada pasta.
Não-eu-Import	Proibir um módulo de se importar.
não-resolvido	Verifique se as importações apontam para um arquivo/módulo que pode ser resolvido.	❗ ☑️
Sem segmentos sem caminho	Proíba segmentos de caminho desnecessário na importação e exigem declarações.				?
sem webpack-carregador-syntax	Proibir a sintaxe do carregador de webpack nas importações.

Guia de estilo

Nome	Descrição		️		?
estilo especificador consistente	Aplicar ou proibir o uso de marcadores somente em linha para importações nomeadas.				?
Dynamic-Import Chunkname	Aplicar um comentário líder com o WebPackChunkName para obter importações dinâmicas.
exportações-last	Verifique se todas as exportações aparecem após outras declarações.
extensões	Garanta o uso consistente da extensão do arquivo dentro do caminho de importação.
primeiro	Verifique se todas as importações aparecem antes de outras declarações.				?
Exportações do grupo	Prefira as exportações nomeadas a serem agrupadas em uma única declaração de exportação
importações primeiro	Substituído por import/first .				?
dependências máximas	Aplicar o número máximo de dependências que um módulo pode ter.
Newline-Após-Import	Aplicar uma nova linha após declarações de importação.				?
Não-anônimo-Default-Export	Proibir valores anônimos como exportações padrão.
sem defesa-exportação	Proibir exportações padrão.
sem duplicações	Proibir a importação repetida do mesmo módulo em vários lugares.		☑️?		?
Não-nome-default	Proibir exportações padrão nomeadas.
sem nome-exportação	Proibir exportações nomeadas.
sem namespace	Proibir o espaço para nome (também conhecido como "curinga" * ) importações.				?
não-assignado-import	Proibir importações não atribuídas
ordem	Aplicar uma convenção na ordem de importação do módulo.				?
prefere default-export	Prefira uma exportação padrão se o módulo exportar um único nome ou vários nomes.

eslint-plugin-import for Enterprise

Disponível como parte da assinatura do Tidelift.

Os mantenedores do eslint-plugin-import e milhares de outros pacotes estão trabalhando com o Tidelift para fornecer suporte e manutenção comercial para as dependências de código aberto que você usa para criar seus aplicativos. Economize tempo, reduza o risco e melhore a saúde do código, enquanto paga aos mantenedores das dependências exatas que você usa. Saber mais.

Instalação

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

Config - Legacy ( .eslintrc )

Todas as regras estão desativadas por padrão. No entanto, você pode estender uma das configurações predefinidas ou configurá -las manualmente em sua .eslintrc.(yml|json|js) .

• Estendendo uma configuração predefinida:

 {
  "extends" : [
     "eslint:recommended" ,
     "plugin:import/recommended" ,
  ] ,
}

• Configurando manualmente:

 {
  "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 )

Todas as regras estão desativadas por padrão. No entanto, você pode configurá -los manualmente em seu eslint.config.(js|cjs|mjs) ou estender uma das configurações predefinidas:

 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

Você pode usar o seguinte snippet ou montar sua própria configuração usando as configurações granulares descritas abaixo.

Certifique-se de instalar @typescript-eslint/parser e eslint-import-resolver-typescript , que são usados ​​na configuração a seguir.

 {
  "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 - FLAT com config() em typescript-eslint

Se você estiver usando o método config do typescript-eslint , verifique se o flatConfig está incluído na 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...
  }
) ; 

Resolvedores

Com o advento dos pacotes do módulo e o estado atual dos módulos e as especificações de sintaxe do módulo, nem sempre é óbvio onde import x from 'module' deve procurar encontrar o arquivo atrás module .

No V0.10ish, este plug -in usou diretamente o plug -in resolve da Substack, que implementa o comportamento de importação do Node. Isso funciona muito bem na maioria dos casos.

No entanto, o WebPack permite várias coisas no módulo de importação strings de origem que o Node não, como carregadores ( import 'file!./whatever' ) e vários esquemas de alias, como externals : mapeando um ID do módulo para um nome global no tempo de execução (permitindo que alguns módulos sejam incluídos mais tradicionalmente via tags de script).

No interesse de apoiar ambos, v0.11 apresenta resolvedores.

Atualmente, a resolução do Node e do Webpack foi implementada, mas os resolvedores são apenas pacotes NPM, para que os pacotes de terceiros sejam suportados (e incentivados!).

Você pode fazer referência aos resolvedores de várias maneiras (em ordem de precedência):

• Como um nome convencional 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 }
    }
  }
}

• Com um nome completo do módulo NPM, como 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 }
    }
  }
}

• Com um caminho de sistema de arquivos para resolver, definido neste exemplo como um nome computed property :

 // .eslintrc.js
module . exports = {
  settings : {
    'import/resolver' : {
      [ path . resolve ( '../../../my-resolver' ) ] : { someConfig : value }
    }
  }
}

Os caminhos relativos serão resolvidos em relação ao package.json mais próximo da fonte ou ao diretório de trabalho atual do processo se nenhum package.json for encontrado.

Se você é interessante ao escrever um resolvedor, consulte as especificações para obter mais detalhes.

Configurações

Você pode definir as seguintes configurações em seu .eslintrc :

import/extensions

Uma lista de extensões de arquivo que serão analisadas como módulos e inspecionadas para export s.

Isso padrão é ['.js'] , a menos que você esteja usando a configuração compartilhada react , nesse caso, é especificada como ['.js', '.jsx'] . Apesar do padrão, se você estiver usando o TypeScript (sem o plugin:import/typescript Config descrito acima), você deve especificar as novas extensões ( .ts e também .tsx se estiver usando o react).

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

Se você precisar de definições de extensão mais granulares, poderá usar:

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

Observe que isso é diferente (e provavelmente um subconjunto de) qualquer configuração de Extensões import/resolver , que pode incluir .json , .coffee , etc., que ainda levará em consideração a regra no-unresolved .

Além disso, os seguintes padrões import/ignore anularão esta lista.

import/ignore

Uma lista de strings regex que, se correspondida por um caminho, não relatará o módulo correspondente se não houver export s. Na prática, isso significa que outras regras que no-unresolved não relatarão nenhuma import com os caminhos (absolutos do sistema de arquivos) que correspondam a esse padrão.

no-unresolved tem sua própria configuração ignore .

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

import/core-modules

Uma matriz de módulos adicionais a serem considerados como módulos "núcleos"-módulos que devem ser considerados resolvidos, mas não têm caminho no sistema de arquivos. Seu resolvedor já pode definir alguns deles (por exemplo, o resolvedor de nós sabe sobre fs e path ), portanto, você não precisa redefini -los.

Por exemplo, o Electron expõe um módulo electron :

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

de outra forma seria não resolvido. Para evitar isso, você pode fornecer electron como um módulo principal:

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

No caso específico da Electron, existe uma configuração compartilhada chamada electron que especifica isso para você.

A contribuição de mais configurações compartilhadas para outras plataformas é bem -vinda!

import/external-module-folders

Uma variedade de pastas. Os módulos resolvidos apenas dessas pastas serão considerados "externos". Por padrão - ["node_modules"] . Faz sentido se você configurou seu caminho ou webpack para lidar com seus caminhos internos de maneira diferente e deseja considerar os módulos de algumas pastas, por exemplo, bower_components ou jspm_modules , como "externo".

Esta opção também é útil em uma configuração Monorepo: Liste aqui todos os diretórios que contêm pacotes da Monorepo e serão tratados como externos, independentemente do resolvedor que seja usado.

Se você estiver usando o pnp yarn como gerenciador de pacotes, adicione a pasta .yarn e todas as dependências instaladas serão consideradas external , em vez de internal .

Cada item nesta matriz é o nome de uma pasta, seu subspato ou seu caminho de prefixo absoluto:

• jspm_modules corresponderá a qualquer arquivo ou pasta denominada jspm_modules ou que possua um pai direto ou não diretamente chamado jspm_modules , por exemplo /home/me/project/jspm_modules ou /home/me/project/jspm_modules/some-pkg/index.js .

• packages/core corresponderão a qualquer caminho que contenha esses dois segmentos, por exemplo /home/me/project/packages/core/src/utils.js .

• /home/me/project/packages corresponderá apenas a arquivos e diretórios dentro deste diretório e o próprio diretório.

Observe que os nomes incompletos não são permitidos aqui, para que components não correspondam bower_components e packages/ui não correspondem packages/ui-utils (mas corresponderão packages/ui/utils ).

import/parsers

Um mapa de analisadores para arquivos de matrizes de extensão. Se uma extensão de arquivo for correspondente, o analisador de dependência exigirá e usará a tecla do mapa como analisador em vez do analisador ESLint configurado. Isso é útil se você estiver interrompendo com o TypeScript diretamente usando o webpack, por exemplo:

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

Nesse caso, @typescript-eslint/parser deve ser instalado e exigir que a localização do módulo eslint em execução (ou seja, instale-o como um colega de ESLint).

Atualmente, isso é testado apenas com @typescript-eslint/parser (e seu antecessor, typescript-eslint-parser ), mas deve teoricamente trabalhar com qualquer analisador compatível com estree moderadamente.

É difícil dizer o quão bem os recursos do plug -in também serão suportados, dependendo da que distância a toca do coelho vai. Envie um problema se encontrar um comportamento estranho além aqui, mas anda seu coração contra o resultado provável de fechar com wontfix .

import/resolver

Veja resolvedores.

import/cache

Configurações para o comportamento do cache. A memórias é usada em vários níveis para evitar a quantidade abundante de chamadas de análise fs.statSync /módulo necessárias para relatar corretamente erros.

Para as execuções normais do console eslint , a vida útil do cache é irrelevante, pois podemos assumir fortemente que os arquivos não devem mudar durante a vida útil do processo do linhador (e, portanto, o cache na memória)

Para processos de longa duração, como eslint_d ou eslint-loader , no entanto, é importante que haja alguma noção de staleness.

Se você nunca usar eslint_d ou eslint-loader , poderá definir a vida útil do cache para Infinity e tudo deve ficar bem:

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

Caso contrário, defina algumas entradas inteiras, e as entradas de cache serão despejadas depois que muitos segundos se passaram:

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

import/internal-regex

Um regex para pacotes deve ser tratado como interno. Útil quando você utiliza uma configuração Monorepo ou desenvolvendo um conjunto de pacotes que dependem um do outro.

Por padrão, qualquer pacote referenciado dos import/external-module-folders será considerado como "externo", incluindo pacotes em um Monorepo, como o ambiente de trabalho de Yarn ou o ambiente de Lerna. Se você deseja marcar esses pacotes como "internos", isso será útil.

Por exemplo, se seus pacotes em um monorepo estiverem todos em @scope , você poderá configurar import/internal-regex como este

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

import/node-version

Uma string que representa a versão do Node.js que você está usando. Um valor falsamente implicará a versão do Node.js com os quais você está executando Eslint.

 // .eslintrc
{
  "settings" : {
    "import/node-version" : "22.3.4" ,
  } ,
} 

Sublimelinter-eslint

O sublimelinter-eslint introduziu uma alteração para oferecer suporte a arquivos .eslintignore que alteraram a maneira como os caminhos dos arquivos são passados ​​para o ESLint ao fazer linhas durante a edição. Essa alteração envia um caminho relativo em vez do caminho absoluto para o arquivo (como o ESLint normalmente fornece), o que pode tornar impossível para esse plug -in resolver as dependências do sistema de arquivos.

Esta solução alternativa não deve mais ser necessária com a liberação do Eslint 2.0, quando .eslintignore será atualizado para trabalhar mais como um .gitignore , que deve apoiar a ignorância adequada dos caminhos absolutos via --stdin-filename .

Enquanto isso, consulte o Roadhump/Sublimelinter-Eslint#58 para obter mais detalhes e discussões, mas essencialmente, você pode achar que precisa adicionar a seguinte configuração SublimeLinter ao seu arquivo sublime de projeto:

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

Observe que ${project}/code corresponde ao code fornecido nas folders[0].path .

O objetivo da configuração chdir , neste caso, é definir o diretório de trabalho a partir do qual o Eslint é executado como o mesmo que o diretório no qual o sublimelinter-eslint baseia o caminho relativo que ele fornece.

Consulte os documentos sublimelinter no chdir para obter mais informações, caso isso não funcione com seu projeto.

Se você não estiver usando .eslintignore , ou não tiver um arquivo de projeto sublime, também pode fazer o seguinte por meio de um arquivo .sublimelinterrc em algum diretório ancestral do seu código:

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

Também descobri que precisava definir rc_search_limit como null , que remove o limite de pesquisa de hierarquia de arquivos ao procurar a árvore do diretório para .sublimelinterrc :

Em Configurações do pacote / Subblimelinter / Usuário Configurações:

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

Acredito que isso padrão é 3 , portanto, talvez você não precise alterá -lo, dependendo da profundidade máxima da pasta do projeto.