Gerador de .editorconfig

O que é um arquivo .editorconfig

Um arquivo .editorconfig manda todos os editores de um projeto concordarem sobre o que é chato: tabulações ou espaços, quantos, qual final de linha, se os espaços sobrando são removidos. Ele fica no seu repositório, a maioria dos editores lê sem precisar de plugin, e ele encerra discussões que de outro modo voltariam a cada revisão de código.

O formato é propositalmente pequeno. Um cabeçalho de seção é um padrão entre colchetes, as linhas abaixo são atribuições de propriedades, e o arquivo no topo do projeto se marca com root = true para a busca parar ali. É quase tudo, e é por isso que as pessoas escrevem um em um minuto e depois passam uma hora se perguntando por que certo arquivo não está pegando as configurações esperadas.

Esta ferramenta faz as duas metades. Você edita o arquivo em cima e, embaixo, informa um caminho e ela diz exatamente qual seção fornece cada propriedade — porque essa é a pergunta que um .editorconfig não responde só de ser lido.

Como usar

1. Comece pelo arquivo mostrado. É um ponto de partida sensato com as propriedades que quase todo projeto quer. Edite direto: acrescente seções, mude valores, apague o que não precisar.
2. Digite um caminho para testar. Relativo a onde o .editorconfig estiver, com barras normais. Teste com um dos seus arquivos problemáticos: aquele que você desconfia que não está recebendo o que você configurou.
3. Veja qual seção venceu. Cada propriedade aplicada aparece com o padrão que a forneceu, e cada seção que casou mostra quantas das suas propriedades sobreviveram. O que fugir da especificação é sinalizado embaixo.

Vence a última, e ser específico não conta nada

Esta é a regra que custa uma tarde a muita gente. Quando duas seções casam com um arquivo, a escrita mais abaixo fornece o valor. O quanto o padrão parece específico não influi em nada: não há pontuação, não há casamento mais específico, nada da maquinaria que o CSS ou as tabelas de rotas ensinaram você a esperar.

Então uma seção ampla no fim do arquivo sobrescreve em silêncio as caprichadas seções por linguagem que estão acima. Se você acrescenta uma regra geral de arrumação ao fim de um .editorconfig longo, acabou de mudar o comportamento de tudo que vem antes para qualquer propriedade que definir. O verificador desta página mostra exatamente isso: cada seção que casou informa quantas das suas propriedades realmente chegaram à resposta final.

Entre arquivos a direção se inverte, e vale guardar isso separado na cabeça. O editor começa no arquivo que você está editando e sobe pela árvore de diretórios, lendo os mais próximos por último para que vençam, e para assim que alcança um que declara root = true. Esqueça essa linha e um .editorconfig num diretório acima — ou na sua pasta pessoal — continua se aplicando ao seu projeto.

A sintaxe de padrões não é a do gitignore

Os padrões parecem os do gitignore e não são, o que é a segunda fonte confiável de surpresa. Além do asterisco e da interrogação de sempre, que param no separador de diretórios enquanto o asterisco duplo não, o EditorConfig tem alternância com chaves e algo que o gitignore nunca teve: um intervalo de inteiros. O padrão file{1..3}.txt casa com file2.txt mas não com file4.txt, e qualquer um dos limites pode ser negativo.

Esse intervalo tem pegadinha, e ela falha em silêncio. O primeiro número precisa ser menor que o segundo, então {3..1} não é intervalo e casa literalmente com esses cinco caracteres. Nada avisa. A mesma armadilha está numa chave de um elemento só: {s1} casa com um arquivo chamado literalmente {s1}, não com um chamado s1, e a especificação diz isso num parêntese fácil de passar batido.

Os colchetes são mais rígidos do que parecem, e este caso pegou também a implementação de referência. A especificação diz que todo caractere dentro dos colchetes é literal, de modo que [a-c] é o conjunto de três caracteres a, hífen e c, e não casa com b. Quase qualquer outra linguagem de padrões do mundo lê a-c como intervalo, e é justamente por isso que vale saber que aqui não.

Por fim, ter ou não uma barra decide o alcance do padrão. Um que tem é medido a partir do diretório onde está o .editorconfig; um que não tem pode casar em qualquer profundidade abaixo. É por isso que [*.py] cobre sua árvore inteira enquanto [src/*.py] cobre exatamente um diretório.

Limitações honestas

Esta página implementa a especificação, e os editores não a implementam de forma uniforme. As sete propriedades aqui são as que a especificação define e para as quais o suporte é razoavelmente confiável, mas um editor pode ignorar qualquer uma delas, e vários dos mais populares precisam de plugin antes mesmo de ler o arquivo. Se uma configuração não está surtindo efeito, verifique se o seu editor suporta aquela propriedade antes de supor que o arquivo está errado.

O verificador também trabalha sobre o arquivo à frente dele. Projetos reais podem ter vários .editorconfig em profundidades diferentes, e a resposta para um caminho depende de todos eles mais de onde a busca para. O que está modelado aqui é um arquivo e as regras dentro dele, que é onde a parte confusa quase sempre mora.

Uma coisa que apareceu ao construir isto vale passar adiante: a implementação de referência e esta ferramenta discordam sobre expressões entre colchetes que contêm caracteres de padrão, e a especificação fica do lado desta. O próprio exemplo resolvido dela é um padrão que a referência erra. É um canto que ninguém escreve de propósito, mas lembra que os casos extremos de um formato de configuração são decididos pelo que o seu editor por acaso traz.

Por que é grátis?

Tudo roda no seu navegador. Casar um caminho com um padrão não custa nada na sua própria máquina, então não há servidor a pagar nem motivo para pedir uma conta.

Nada do que você digita é enviado, guardado ou registrado. A estrutura de diretórios e os nomes de arquivo dizem bastante sobre uma base de código privada, e o jeito confiável de manter isso privado é não mandar para lugar nenhum.