Início·Mensagens de erro

Mensagens de erro, explicadas

104 mensagens de erro, com o que significam, por que apareceram e o que fazer.

As correções têm custo. git reset --hard descarta trabalho não commitado, um force push pode destruir os commits de outra pessoa e docker system prune apaga volumes sem nome. Onde é o caso, a ficha avisa.

Git29

Quase todo erro do git é uma recusa que quer dizer "fazer isso a partir deste estado perderia algo"; fatal: significa que o git parou sem alterar nada, e as linhas hint: abaixo da primeira normalmente trazem a solução de verdade.

fatal: refusing to merge unrelated historiesOs dois lados que você quer mesclar não têm nenhum ancestral comum, então para o git são dois projetos estranhos entre si. Costuma aparecer quando você começou local com git init, fez alguns commits e depois apontou para um remoto que já tinha commits próprios e deu pull. O --allow-unrelated-histories mescla mesmo, mas solda duas histórias alheias num único commit e desfazer isso depois dá muito trabalho; com poucos commits locais é mais limpo clonar o remoto de novo e copiar seus arquivos para dentro.Your branch and 'origin/main' have divergedSeu branch e o origin/main têm, cada um, commits que o outro não tem: a linha da história se partiu em duas. Acontece quando você commitou local enquanto outra pessoa deu push, ou quando reescreveu com amend ou rebase commits que já havia enviado. O git pull --rebase reaplica seus commits sobre os deles e mantém uma linha só, mas dá hashes novos aos seus commits, então se você já os havia compartilhado o mesmo trabalho fica registrado duas vezes; aí o --no-rebase, que deixa um único commit de merge, é mais seguro.fatal: Need to specify how to reconcile divergent branches.Desde o git 2.34, o pull não adivinha se deve mesclar ou fazer rebase quando os branches divergiram: ele pede uma configuração, não relata um estrago. Aparece quando os branches divergiram e você nunca configurou pull.rebase. pull.ff only é a resposta mais segura porque só puxa quando pode avançar e, se não, para sem criar nada; pull.rebase true reescreve os hashes dos seus commits locais toda vez, e false deixa um commit de merge.CONFLICT (content): Merge conflict in src/app.tsxOs dois lados mudaram as mesmas linhas de formas diferentes e o git não pode decidir qual vale, então escreveu as duas versões dentro do arquivo entre <<<<<<<, ======= e >>>>>>> e parou. Acontece quando você e outra pessoa editam a mesma região, ou quando um rebase leva seu commit por cima de uma edição dessas linhas. Abra o arquivo, deixe-o como deve ficar, apague os marcadores e faça git add e commit. O git merge --abort volta exatamente ao estado antes do merge, o que é seguro para tudo já commitado, mas descarta as resoluções que você tinha feito à mão.Please commit your changes or stash them before you merge.Os arquivos com edições não commitadas também são tocados pelos commits que estão chegando, e o git preferiu parar a sobrescrevê-los. Aparece quando você dá pull ou merge com a árvore de trabalho suja. O git stash push -u guarda essas edições de lado para o merge passar, e o -u inclui também arquivos não rastreados; mas o git stash pop pode conflitar na volta, e um stash não aparece ao lado dos seus branches, sendo fácil de esquecer e perder — fazer um commit temporário é o hábito mais seguro.error: Your local changes to the following files would be overwritten by checkout:Você está tentando trocar de branch, mas arquivos cujo conteúdo é diferente lá ainda têm edições que você não commitou. Aparece quando você faz switch ou checkout com o trabalho pela metade. O git stash push -u, ou um commit temporário, te leva para o outro lado e permite voltar depois. O git checkout --force e o git switch --discard-changes que aparecem nas buscas realmente movem você, mas apagam essas edições não commitadas para sempre: nada as registra, nem o reflog, então não há volta.You are currently rebasing branch 'feature' on '8a3f21c'.Um rebase começou e parou no meio, e o HEAD está estacionado num estado temporário em vez de no seu branch. Você vê esta linha depois de um conflito durante o rebase, ou depois de uma parada edit ou break no git rebase -i, quando foi fazer outra coisa sem terminar. Resolva o conflito, dê git add e siga com git rebase --continue, ou use --skip se pretende descartar aquele commit. O git rebase --abort devolve você exatamente ao ponto anterior ao rebase, então nada commitado se perde, mas as resoluções feitas até agora vão junto.You are in 'detached HEAD' state.O HEAD aponta direto para um commit em vez de para um nome de branch, então qualquer commit feito aqui não fica ligado a nome nenhum. Você cai nisso ao fazer checkout de um hash ou de uma tag, ao trabalhar dentro de um submódulo, ou porque a CI fez checkout de um commit específico. Para guardar o que fez, git switch -c nome cria um branch aqui mesmo e não perde nada. Se você só fizer git switch main, os commits criados ficam sem nada apontando para eles: o reflog ainda os acha por um tempo e depois a coleta de lixo os remove.Warning: you are leaving 1 commit behind, not connected to any of your branches:Ele avisa que você commitou em estado detached HEAD e agora está saindo, sem nenhum branch apontando para esses commits. Acontece quando você fez checkout de um hash, trabalhou, commitou e depois voltou para um branch. Use o hash impresso na mensagem: git branch rescue 8a3f21c prende os commits a um nome, e esse comando não muda nada além disso, apenas acrescenta um nome. Se você já saiu, o git reflog ainda os lista, mas commits sem nada apontando para eles somem quando a coleta de lixo roda, o que por padrão significa cerca de trinta dias.error: failed to push some refs to 'https://github.com/user/repo.git'O servidor recusou o seu push, e esta linha é só o resumo: o motivo real está na linha ! [rejected] logo acima. Normalmente o remoto tem commits que você não tem, mas um branch protegido, um hook do servidor ou um limite de tamanho de arquivo produzem o mesmo resumo. Leia primeiro o motivo; no caso comum, git pull --rebase && git push encerra o assunto. O perigoso é acrescentar --force sem ler, porque isso pode apagar do servidor os commits de um colega.! [rejected] main -> main (fetch first)O branch remoto tem commits que o seu clone nunca viu, então dar push agora não seria um avanço rápido. Acontece quando um colega deu push antes, ou quando você não faz fetch há muito tempo. O git pull --rebase origin main traz esses commits e reaplica os seus por cima, e então o push passa. Nunca recorra ao --force aqui: os commits que você sobrescreveria são de outra pessoa e não estão no seu repositório, então nada local consegue trazê-los de volta.! [rejected] main -> main (non-fast-forward)Seu branch não é descendente do branch remoto, então dar push como está descartaria commits que existem no servidor. Acontece quando você reescreveu com rebase, amend ou reset commits já enviados. Se a reescrita foi intencional e o branch é só seu, use git push --force-with-lease: ele recusa se o remoto se moveu desde o seu último fetch, então, diferente do --force puro, não consegue apagar em silêncio o push de um colega que entrou no meio. Se não foi intencional, a resposta é pull --rebase, não forçar.Updates were rejected because the remote contains work that you do not have locally.Esta é a explicação por trás de um push recusado: o remoto contém trabalho que o seu clone não tem, e dar push agora o removeria. Aparece quando várias pessoas compartilham um branch, ou quando você editou e commitou um arquivo pela interface web e nunca o baixou. Faça primeiro git pull --rebase origin main e depois push, e ele passa direto. Acrescentar --force apesar deste aviso faz exatamente o que o aviso existe para evitar: os commits da outra pessoa desaparecem do servidor e, se ninguém deu fetch depois do push dela, não existem em lugar algum.error: src refspec main does not match anyO nome que você pediu para enviar não existe localmente nem como branch nem como tag, e não é possível mandar o que não está lá. Acontece em um repositório novinho sem commits, onde main ainda não existe; ou quando seu branch local é master e você digitou main; ou é só um erro de digitação. git push -u origin HEAD envia o branch em que você realmente está, com o nome real dele, e resolve o caso do nome trocado de uma vez. Se não há commit nenhum, faça um primeiro: repositório vazio não tem o que enviar.fatal: The current branch feature has no upstream branch.Este branch não tem contrapartida remota registrada, então um git push ou git pull sem argumentos não sabe para onde ir. Acontece quando você criou um branch com git switch -c e nunca o enviou. O git push --set-upstream origin feature cria o branch no servidor e registra o par uma vez só; daí em diante basta git push. O comando escreve apenas uma linha de configuração local e um branch novo no servidor, então não apaga nada e é seguro repetir.error: cannot lock ref 'refs/remotes/origin/main': is at 8a3f21c but expected 1c2d3e4No momento em que o git ia escrever um valor novo numa referência de rastreamento remoto, encontrou um valor diferente do que tinha acabado de ler e recusou sobrescrever. Costuma acontecer quando o seu editor faz fetch em segundo plano enquanto você também faz fetch, ou quando alguém deu force push e as suas referências de rastreamento ficaram fora de compasso. Repetir o fetch normalmente resolve. O git remote prune origin limpa referências de rastreamento cujos branches já não existem lá em cima; ele apaga só as cópias dentro do seu repositório e nunca mexe num branch do servidor.fatal: not a git repository (or any of the parent directories): .gitNão existe .git neste diretório nem em nenhum acima dele, então o git não achou um repositório. Acontece quando você está um nível acima ou abaixo do repositório, quando um clone caiu em outra pasta, ou quando você nunca rodou git init. Confira primeiro onde está com pwd e use git init só se realmente quiser começar um repositório aqui. Rodar git init dentro de uma subpasta de um repositório existente cria um segundo repositório aninhado que encobre o de fora em silêncio, e daí em diante os arquivos daquela pasta nunca entram nos commits externos.fatal: remote origin already exists.O nome origin já está em uso neste repositório, então não pode ser criado de novo. Um repositório clonado tem origin desde o começo, e a mensagem aparece quando você segue dentro dele um guia de repositório novo e roda git remote add origin. Veja primeiro para onde origin aponta com git remote -v; se o que você queria era outra URL, git remote set-url origin muda só o destino. Esse ajuste é uma linha do .git/config, reversível a qualquer momento e sem efeito nos seus commits.error: pathspec 'featue' did not match any file(s) known to gitO git não achou nenhum arquivo, branch ou tag com esse nome: a cadeia entre as aspas é exatamente o que ele procurou. Acontece por erro de digitação, porque o branch só existe no servidor e você não deu fetch, ou porque o arquivo está em outro diretório que não o que você supôs. Se for branch, faça git fetch e depois git branch -a e compare o nome no olho; se for arquivo, git status --short mostra os caminhos reais. Lembre que os caminhos nos comandos do git são lidos em relação ao diretório onde você está, não à raiz do repositório, e só isso explica muitos desses casos.git@github.com: Permission denied (publickey).O ssh chegou ao servidor mas não ofereceu nenhuma chave que o servidor aceite: é autenticação, não rede. Acontece quando você não gerou chave, quando tem uma mas nunca a adicionou ao ssh-agent, ou quando a chave pública não está registrada na sua conta naquele serviço. O ssh-add ~/.ssh/id_ed25519 carrega a chave no agente durante esta sessão, e o ssh -T git@github.com informa qual chave foi tentada e como você é reconhecido. Os dois comandos só leem; não há nada a perder.remote: Support for password authentication was removed on August 13, 2021.O GitHub deixou de aceitar senhas de conta por https em 2021: a sua senha não está errada, é o método que já não é aceito. Aparece quando a credencial guardada é uma senha antiga, ou quando você digitou uma no prompt. Para continuar no https, coloque um personal access token no campo de senha; senão, troque para o endereço ssh com git remote set-url origin. Mudar o endereço remoto é uma linha de configuração no seu próprio clone, então não mexe em commit nenhum e é reversível a qualquer momento.fatal: Authentication failed for 'https://github.com/user/repo.git/'A credencial enviada foi recusada: está errada, expirou, ou é um token sem o escopo que este repositório precisa. A armadilha comum é um token expirado ainda em cache no seu credential helper: ele é enviado sem nunca perguntar nada, então você recebe a mesma linha sempre. A linha git credential reject do conserto remove só aquela entrada guardada, para que você seja perguntado de novo e possa colar um token novo. Ela apaga apenas a credencial salva e não mexe em nenhum dado do repositório.fatal: Unable to create '/repo/.git/index.lock': File exists.O git cria .git/index.lock como trava enquanto escreve o índice, então o arquivo já existir significa que outro git está rodando ou que um morreu e o deixou. Ele fica para trás por causa de um editor ou IDE rodando git em segundo plano, ou de um comando que você interrompeu com Ctrl+C ou matou. Confirme que nenhum git está rodando e apague com rm -f .git/index.lock. Apagar enquanto um processo git realmente trabalha pode corromper o índice, então verifique antes; se o índice ficar errado, git reset o reconstrói a partir do HEAD, e sem --hard ele não toca nos seus arquivos.nothing to commit, working tree cleanNão é um erro: o git está dizendo que nada difere do último commit, então não fez nada. Você vê isso quando o arquivo editado é capturado pelo .gitignore, quando o lugar que você editou é outro clone ou worktree diferente daquele em que está, ou quando já commitou e esqueceu. git check-ignore -v <caminho> imprime a linha exata do .gitignore que esconde um arquivo, e git log -1 mostra se a mudança já entrou. Os dois comandos só leem.error: unable to unlink old 'dist/main.js': Permission deniedUm checkout quis substituir um arquivo por uma versão nova e o sistema operacional recusou remover o antigo. Acontece quando outro programa o mantém aberto, o que é especialmente comum no Windows, ou quando você não tem permissão de escrita no diretório. Feche o que o segura — servidor de desenvolvimento, editor, antivírus — e rode o mesmo comando de novo; no Unix, corrija a permissão do diretório. Repetir o comando é seguro, mas note que o git parou no meio, então a árvore de trabalho fica meio atualizada até dar certo.fatal: bad object 8a3f21cO nome que você deu não resolve para nada que o git consiga ler: ou o objeto não está neste repositório, ou está e é danificado. Acontece com um hash copiado de outro clone ou de um clone raso, com um hash truncado curto demais, ou com um objeto realmente corrompido depois de um problema de disco. O git fsck --full relata objetos ausentes e quebrados só lendo, e um hash de outra pessoa precisa de um git fetch antes de o objeto existir aqui. Se o fsck relatar corrupção, clonar de novo é mais rápido e certo que reparar — copie antes os seus arquivos não commitados para um lugar seguro.warning: LF will be replaced by CRLF in package.json.É um aviso, não um erro: o core.autocrlf está ligado, então o git guarda LF no commit mas escreverá CRLF na sua cópia de trabalho. Instalar o git no Windows com os padrões deixa autocrlf em true, então aparece em todo add naquela máquina. git config core.autocrlf input guarda LF e para de converter na extração, e a resposta melhor é um .gitattributes no repositório com * text=auto eol=lf, para todos os clones se comportarem igual. Mudar o ajuste pode fazer todos os arquivos parecerem modificados uma vez; isso é uma única reextração, não trabalho perdido.The file will have its original line endings in your working directoryÉ a segunda metade do aviso de CRLF acima: diz que o arquivo em disco mantém os finais de linha que já tem e que só a cópia guardada no commit é normalizada. Vem do mesmo ajuste autocrlf, então por si só nada está quebrado. Mas se os diffs mostram arquivos inteiros alterados, é sinal de que os finais de linha da equipe divergem: fixe a regra com um .gitattributes no repositório e rode git add --renormalize . uma vez. Esse comando reescreve só como os finais são guardados, não o conteúdo dos arquivos.husky - pre-commit hook exited with code 1 (error)O seu commit nunca foi criado: um hook — lint, testes, um formatador — saiu com código diferente de zero e o git abortou. O motivo real não está nesta linha, mas na saída do próprio hook acima dela, normalmente uma regra de lint ou um erro de tipos. Corrigir o que o hook apontou e commitar de novo é a única resposta de verdade. O git commit --no-verify pula todos os hooks de commit e realmente gera um commit, mas não passou pela verificação: apenas empurrou a falha para a CI, e código sem formatação vai direto para os seus colegas.

npm20

No npm a causa está na primeira linha code XXXX e não nas seis últimas linhas npm ERR!, e quando a falha vem da árvore de dependências ou de uma compilação nativa em vez do seu código, apagar node_modules e instalar de novo resolve metade dos casos.

npm ERR! ERESOLVE unable to resolve dependency treeA partir do npm 7 os intervalos de peerDependencies são exigidos, e isto diz que o npm não achou um conjunto de versões que satisfaça todos ao mesmo tempo. É comum quando o pacote que você instala tem um intervalo de peer que exclui a versão de react ou typescript que você já tem, sobretudo logo depois de subir uma versão maior. Leia as linhas Found: e Could not resolve: para ver quem exige o quê e mova um dos dois para uma versão compatível: esse é o conserto de verdade. O npm install --legacy-peer-deps instala ignorando por completo os intervalos de peer, o que te desbloqueia mas deixa uma árvore que os pacotes nunca aceitaram, então os erros em execução por versões desencontradas ficam para você.npm ERR! Conflicting peer dependency: react@18.3.1Esta linha aponta o par que realmente colide dentro do relatório do ERESOLVE: este pacote exige aquela versão de um peer enquanto a sua árvore tem outra. Normalmente significa que a biblioteca principal subiu de versão maior e um plugin que a usa ainda não acompanhou. Perguntar pelo nome com npm ls react imprime, em forma de árvore, quem pediu qual versão, e ali mesmo fica claro qual dos dois precisa se mover. Atualizar o plugin é o conserto de verdade; --force escreve a árvore desencontrada de qualquer jeito e esconde o problema até a execução.npm WARN react-dom@17.0.2 requires a peer of react@17.0.2 but none is installed.O npm 6 apenas avisava sobre dependências peer e nunca as instalava para você: o pacote está presente, mas o companheiro que ele diz precisar não. Aparece num projeto ainda no npm 6, ou quando você usa um lockfile antigo daquela época. Instale você mesmo o peer indicado numa versão dentro do intervalo impresso e está resolvido. Nada falhou ainda porque isto é só um aviso, mas volta depois como Cannot find module, ou como duas cópias da mesma biblioteca gerando erros sem sentido.npm WARN deprecated request@2.88.2: request has been deprecatedO autor do pacote marcou aquela versão como não mais recomendada: ela instalou e continua funcionando. Normalmente não é algo do seu próprio package.json, mas uma dependência transitiva arrastada por um pacote que você usa. Perguntar pelo nome com npm ls request mostra qual das suas dependências diretas a traz, e o lugar de consertar é essa dependência direta, não este pacote. Hoje não há nada a fazer: deprecated não é vulnerabilidade de segurança, e disso quem fala é o npm audit.npm ERR! npm ci can only install packages when your package.json and package-lock.json or npm-shrinkwrap.json are in sync.O npm ci instala estritamente o que o lockfile registra, e parou antes de começar porque o package.json pede algo que o lockfile não contém. Acontece quando alguém editou o package.json à mão ou resolveu um conflito nele sem rodar install, ou commitou o package.json sem o lockfile ao lado. Rode npm install localmente uma vez para o lockfile bater e então commite o lockfile: esse é o conserto inteiro. Apagar o package-lock.json para escapar disso reresolve todas as dependências para versões mais novas e muda em silêncio o que a sua compilação contém.npm ERR! The `npm ci` command can only install with an existing package-lock.json or npm-shrinkwrap.jsonO npm ci não roda de jeito nenhum sem lockfile, porque não tem nada dizendo quais versões instalar. Acontece quando o package-lock.json está no .gitignore, nunca foi commitado, ou quando o diretório em que você está não é a raiz do projeto. O npm install --package-lock-only escreve o lockfile sem instalar nada, e commitá-lo faz a CI funcionar. Nunca coloque package-lock.json no .gitignore: a garantia de que a CI compila a mesma coisa duas vezes se apoia nesse único arquivo.npm ERR! Invalid Version:O campo version do package.json não é semver válido, então o npm não consegue interpretar o pacote de jeito nenhum. Acontece com um valor editado à mão como 1.0 ou v1.0.0 ou uma string vazia, sobretudo depois de um conflito mal resolvido nesse arquivo. O npm pkg set version=1.0.0 escreve de volta uma versão de três partes correta. O comando edita só o package.json e não toca em node_modules nem no lockfile, então em seguida todo comando que lê o arquivo volta a funcionar na hora.npm ERR! 404 Not Found - GET https://registry.npmjs.org/@acme/ui - Not foundO registro não tem pacote com esse nome — um 404 é uma resposta sobre o nome, não sobre a sua rede nem as suas credenciais. Acontece por erro de digitação, por um pacote que foi despublicado, ou por um scope privado no qual você não está autenticado. Um pacote privado parece exatamente igual a um inexistente para quem não tem acesso, e é por isso que os três casos caem nesta única linha. npm view @acme/ui version confirma se o nome existe publicamente, e para um scope privado verifique se o .npmrc tem o registro e o token daquele scope. As duas verificações só leem.npm ERR! request to https://registry.npmjs.org/express failed, reason: unable to verify the first certificateA conexão TLS falhou: a cadeia de certificados que o servidor apresentou sobe até uma autoridade em que o node não confia. Na esmagadora maioria é uma rede corporativa cujo proxy abre o tráfego e o reassina com o próprio certificado; às vezes é um servidor que não enviou o certificado intermediário. Ensinar ao npm a raiz da sua empresa com npm config set cafile é o conserto correto. O strict-ssl false também faz esta linha desaparecer, mas desliga a verificação de certificados por completo, o que permite que qualquer um no caminho lhe entregue pacotes alterados: não use.npm ERR! code EINTEGRITYO hash do tarball que o npm baixou não bate com o que o lockfile registra, então o npm decidiu que não pode confiar no que chegou e parou. É uma entrada de cache corrompida, ou um proxy que alterou o download, ou mais raramente um lockfile cujo valor integrity foi editado à mão ou mal mesclado. O npm cache clean --force esvazia o cache local para a próxima instalação baixar de novo; ele apaga só cópias em cache e é seguro repetir. Se continuar acontecendo com um pacote específico, o próprio integrity registrado está errado e essa entrada precisa ser reresolvida com npm install.npm ERR! Error: EACCES: permission denied, access '/usr/local/lib/node_modules'O npm tentou escrever num diretório do sistema que o seu usuário não possui: o pacote está bem, você simplesmente não tem direito de escrever ali. É quase sempre npm install -g contra um node que o gerenciador de pacotes do sistema colocou num lugar como /usr/local. npm config set prefix ~/.npm-global move as instalações globais para o seu diretório pessoal e, com o bin dele no PATH, o erro não volta. sudo npm install -g funciona, mas deixa arquivos de dono root no cache e no node_modules que geram o mesmo EACCES em instalações comuns mais tarde; um gerenciador de versões como o nvm elimina toda essa classe de problema.npm ERR! enoent ENOENT: no such file or directory, open '/home/me/package.json'O npm procurou package.json no diretório atual e subindo a árvore e não achou nenhum: você rodou um comando npm num lugar que não é um projeto. Acontece quando você está na raiz de um monorepo e o projeto está numa subpasta, quando está ao lado da pasta que clonou, ou quando simplesmente esqueceu o cd. A resposta é ir para a pasta que tem package.json, e um ls é o jeito mais rápido de ver. Use npm init -y só se realmente quiser começar um projeto novo aqui: na pasta errada ele deixa um package.json solto que confunde as ferramentas depois.npm ERR! code ELIFECYCLEUm script do package.json saiu com código diferente de zero: ELIFECYCLE é o invólucro do npm em volta disso, não a causa. A causa é o que o seu script de build ou de testes fez, e as linhas do erro real estão acima desta. Suba até o primeiro erro, ou rode à mão o comando real impresso depois de npm ERR! <pkg>@<ver> <script>: para ver a saída sem o invólucro do npm. O código de saída que vem depois também diz algo: 1 é uma falha comum, enquanto 137 significa que o processo foi morto, tipicamente por memória.gyp ERR! build errorUma dependência contém C ou C++ que precisa ser compilado na sua máquina na hora da instalação, e essa compilação falhou: o node-gyp precisa de um compilador e de python. Acontece quando não há nenhuma cadeia de compilação instalada, ou quando o pacote é mais antigo que o seu node e os headers já não combinam. Instale as ferramentas: xcode-select --install para as ferramentas de linha de comando no macOS, build-essential e python3 no Debian ou Ubuntu, a carga de trabalho C++ do Visual Studio no Windows. Se uma versão mais nova do pacote traz um binário pré-compilado para o seu node, subir o pacote é bem mais rápido que arrumar o ambiente de compilação.Error: Cannot find module 'express'O node não conseguiu resolver esse nome para nenhum arquivo: ele não está em node_modules, ou você rodou de um diretório sem node_modules. Acontece quando você nunca instalou, quando uma instalação falhou no meio e deixou uma árvore parcial, ou quando o pacote está em devDependencies e você instalou com --omit=dev. rm -rf node_modules && npm install reconstrói a árvore a partir do lockfile; é seguro, não perde nada e custa só o tempo de download. Mas se o nome entre aspas é um caminho relativo começando com ./, não falta pacote nenhum: o caminho no seu próprio código está errado.Module not found: Error: Can't resolve './components/Button' in '/app/src'O empacotador não achou aquele arquivo naquele caminho — este é o seu próprio import, não um pacote. Acontece quando o caminho relativo está deslocado um nível, quando a extensão falta ou está errada, ou quando as maiúsculas do nome do arquivo diferem do import. O último é o mais traiçoeiro: os sistemas de arquivos do macOS e do Windows não distinguem maiúsculas, então funciona na sua máquina e quebra só na CI Linux. Faça ls do diretório e compare com o import caractere por caractere, maiúsculas incluídas. Se o nome for um pacote e não um caminho, instale-o; em nenhum dos casos algo é apagado.Error: error:0308010C:digital envelope routines::unsupportedO node 17 passou a trazer o OpenSSL 3, que tirou dos padrões um algoritmo de hash antigo, e uma ferramenta que ainda o pede cai exatamente dentro dessa chamada. É quase sempre um webpack 4 antigo, ou uma ferramenta que embute um, rodando num node moderno. export NODE_OPTIONS=--openssl-legacy-provider reabilita os algoritmos antigos para aquele processo e é inofensivo para uma compilação. Mas isso mantém viva uma ferramenta morta: subir para o webpack 5, ou para a versão atual do seu framework, elimina de vez a necessidade da opção.FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memoryO heap do V8 bateu no teto e o node desistiu por conta própria: o sistema operacional não o matou, o node concluiu que não podia crescer mais e parou. A causa é uma verificação de tipos ou um empacotamento grande, uma compilação com source maps num projeto grande, ou código com vazamento como acumular tudo num array. export NODE_OPTIONS=--max-old-space-size=4096 sobe o teto para 4 GB e muitas vezes basta, mas a máquina precisa ter essa RAM de fato, e se o limite de um contêiner for menor o sistema operacional mata o processo, o que aparece como código de saída 137. Se o número precisa crescer sempre, a causa é um vazamento e não o limite.npm WARN EBADENGINE Unsupported engineAlgum pacote declara um intervalo de engines para node ou npm que o seu ambiente não satisfaz — o npm apenas avisa e instala do mesmo jeito. Acontece quando você está num node antigo instalado como pacote do sistema, ou quando o projeto passou para um node mais novo que o do seu shell. Troque o node para uma versão dentro do intervalo impresso com o seu gerenciador de versões; o que vale é o .nvmrc do projeto ou o campo engines do package.json. Por padrão é só um aviso, mas com engine-strict=true no .npmrc a mesma condição se torna um erro que interrompe a instalação.zsh: command not found: tscO shell percorreu o PATH e não achou nenhum executável com esse nome — a instalação em si pode muito bem ter dado certo. Acontece quando o diretório bin global do npm não está no PATH, quando você instalou local em vez de global e o binário foi para node_modules/.bin, ou quando o shell guarda um PATH antigo em cache. npx tsc --version roda a cópia local sem tocar no PATH, então essa única linha separa não instalado de não está no PATH. Para uma instalação realmente global, acrescente ao PATH a saída de npm prefix -g mais /bin e abra um shell novo.

JavaScript15

Erros de navegador e de Node costumam dizer o que quebrou e não por que o valor ficou assim — você leu undefined, não era uma função, não era JSON — então o lugar de corrigir está acima da linha que estourou, e calar só aquela linha com ?. e valores padrão faz o mesmo problema reaparecer mais longe, numa forma mais difícil de reconhecer.

Uncaught TypeError: Cannot read properties of undefined (reading 'name')O valor à esquerda do ponto é undefined e você leu uma propriedade dele; o nome entre parênteses é a propriedade que você queria, então o que está quebrado é o valor anterior. Vem de uma resposta que ainda não chegou, de uma prop que ninguém passou, de um nível a mais como em data.user.name, ou de arr[0].id num array vazio. Onde o valor é de fato opcional, user?.name interrompe o caminho; mas se o valor deveria existir, ?. apenas troca o erro por um undefined que falha na linha seguinte, então descubra acima por que ele é undefined. Antes do Chrome 78 o mesmo erro dizia Cannot read property 'name' of undefined.TypeError: items.map is not a functionO nome existe, mas não é uma função — se não existisse, a mensagem falaria de undefined. Causas típicas: algo que você tomou por array e é na verdade um objeto ou um NodeList, uma API que devolve {data: [...]} em vez do array, ou o formato errado do export default de um módulo. Imprima antes de teorizar: um console.log(typeof items, items) resolve metade desses casos na hora. Um NodeList ou Set só precisa de Array.from(items); mas se era {data: [...]}, embrulhar está errado e o certo é items = res.data.RangeError: Maximum call stack size exceededAs chamadas empilharam mais fundo do que o motor permite, e em geral não é recursão profunda, é recursão sem fim. Uma função cuja condição de parada falta ou nunca é atingida, duas funções chamando uma à outra, JSON.stringify num objeto que contém a si mesmo, ou no React um render que altera o estado do qual depende. A pilha no console repete dois ou três quadros: esse par é o laço, e o caso base pertence ali. Se o cálculo precisa mesmo de profundidade, reescrever a recursão como laço ou pilha explícita é o único caminho: num navegador não se aumenta o limite da pilha.SyntaxError: Unexpected token '<', "<!DOCTYPE "... is not valid JSONO que você passou a JSON.parse era HTML, não JSON. O fragmento <!DOCTYPE citado na mensagem é a prova, e quer dizer que o servidor respondeu com uma página HTML — um 404, um 502 ou um redirecionamento de login — então o bug real está antes do parse, na requisição. Causas típicas: URL errada, um proxy do servidor de desenvolvimento que serviu index.html em vez da API, ou uma sessão expirada que redirecionou para a tela de login. Verifique res.ok antes de chamar res.json() e leia res.text() para ver o que chegou; bater na URL com curl -s é o jeito mais rápido de olhar. Antes do Chrome 111 e do Node 20 o mesmo erro dizia Unexpected token < in JSON at position 0.SyntaxError: Unexpected end of JSON inputO parser chegou ao fim do documento ainda lendo JSON e, quase sempre, o corpo estava simplesmente vazio. Chamar res.json() num 204 No Content ou numa resposta de erro sem corpo, ler o corpo duas vezes e a segunda vir vazia, ou ler um arquivo truncado no meio da escrita. Pegue o texto primeiro e verifique antes de analisar — const t = await res.text(); if (!t) return null; — o que dá um diagnóstico exato. Encobrir com JSON.parse(text || 'null') faz uma resposta vazia parecer normal, então descubra primeiro por que o servidor mandou corpo vazio.TypeError: Failed to fetchA requisição terminou sem resposta, e o navegador esconde o motivo de propósito: um bloqueio de CORS, um endereço morto, um certificado inválido e uma extensão bloqueadora de anúncios geram as mesmas duas palavras. É um erro lançado, não um status, então um 404 ou um 500 nunca chega aqui — o servidor não chegou nem a responder. Normalmente há uma segunda linha mais específica logo acima no console ou na aba Network, então leia-a primeiro; e bater na URL com curl -i separa "o servidor caiu" de "o navegador recusou". O Firefox escreve a mesma situação como NetworkError when attempting to fetch resource.Access to fetch at 'https://api.example.com/data' from origin 'http://localhost:3000' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.A requisição chegou ao servidor e uma resposta voltou, mas essa resposta não trazia cabeçalho permitindo esta origem, então o navegador recusou entregá-la ao seu JavaScript. Só navegadores aplicam essa regra, e é por isso que a mesma URL funciona no curl — parece que o servidor está bem e só o navegador está quebrado. A correção mora sempre no servidor: acrescente Access-Control-Allow-Origin: http://localhost:3000 à resposta. O front-end não pode fazer nada e, se o servidor não é seu, passar a chamada pelo seu próprio é o único caminho. Allow-Origin: * não vale para requisições que enviam cookies; essas exigem a origem exata mais Allow-Credentials.SyntaxError: Cannot use import statement outside a moduleO Node ou o navegador leram aquele arquivo como um script CommonJS, e dentro havia a palavra-chave ESM import. Um arquivo .js é CommonJS a menos que o package.json diga o contrário, e no navegador acontece o mesmo quando a tag <script> não tem type="module". npm pkg set type=module declara o pacote inteiro como ESM e resolve, mas a partir dali todo .js do pacote perde require e __dirname, então os arquivos CommonJS restantes também precisam migrar — se você só quer converter um arquivo, renomeá-lo para .mjs é a mudança mais estreita e segura.ReferenceError: require is not defined in ES module scope, you can use import insteadEste é o espelho exato do erro anterior: o arquivo está sendo lido como ESM e contém o require do CommonJS. Acontece quase sempre logo depois de adicionar "type": "module" ao package.json com scripts antigos ainda na árvore. Para deixar aquele arquivo no mundo antigo, mv script.js script.cjs é a mudança mais estreita; para migrá-lo, reescrever require como import também exige lidar com __dirname e require.main === module, que não existem em ESM.Error [ERR_MODULE_NOT_FOUND]: Cannot find module '/app/src/util' imported from /app/src/index.jsQuando o Node executa ESM, ele trata os caminhos de import como nomes de arquivo literais, como um navegador faz, então './util' não é './util.js' — é um arquivo que não existe. O CommonJS tentava extensões por você, e o TypeScript deixa os imports sem extensão intactos na compilação, por isso um projeto construído com tsc solta um monte destes na primeira vez que você roda com node. Acrescente a extensão .js aos imports relativos; dentro de um arquivo TypeScript você também escreve './util.js', porque o que o Node vai ler é a saída compilada. Nomes de pacotes do node_modules não levam extensão.ReferenceError: window is not definedO código rodou dentro do Node no servidor, não num navegador. O Node não tem window, nem document, nem localStorage, então tocar window enquanto um módulo é carregado num framework que renderiza primeiro no servidor, como Next.js ou Nuxt, para aqui — muitas vezes é uma única linha fora do componente, ou o próprio import de uma biblioteca só de navegador. Se o trabalho é só de navegador, proteja com typeof window !== 'undefined' ou, melhor, mova para dentro de useEffect, que só roda no navegador. Quando toda uma biblioteca é só de navegador, o Next.js pode excluí-la do render do servidor com dynamic(() => import('./C'), { ssr: false }) — ao custo de aquela parte não aparecer no HTML gerado no servidor.Hydration failed because the initial UI does not match what was rendered on the serverO HTML que o servidor enviou e o que o navegador produziu no primeiro render são diferentes, então o React não conseguiu ligar um ao outro. Usar new Date() ou Math.random() durante o render, ler localStorage, ou desenhar conforme a largura de window garante duas respostas distintas — e o mesmo vale para marcação que o navegador conserta em silêncio, como um <div> dentro de um <p>. A regra é renderizar na primeira passada exatamente o que o servidor renderizou e mudar depois que useEffect rodar; o custo é que a parte diferente aparece um instante depois e não está no HTML do servidor. O React 19 escreve a mesma situação como "the server rendered HTML didn't match the client" e mostra um diff do que divergiu.Objects are not valid as a React child (found: object with keys {name, id})O valor que você pediu para o React renderizar é um objeto, não uma string nem um número, e a lista de chaves entre parênteses diz qual objeto é. Normalmente a linha deveria ser {user.name} onde está {user}, ou você tentou renderizar uma resposta inteira. Se em vez de uma lista de chaves aparecer found: [object Promise], a causa é outra: você renderizou o resultado de uma função async sem await. A correção é escolher o campo a exibir; JSON.stringify(user) serve para uma olhada rápida ao depurar, mas não deixe na tela.Each child in a list should have a unique "key" prop.Os elementos irmãos renderizados como lista não têm key, então o React não consegue pareá-los com os mesmos itens no próximo render. Você criou os elementos com items.map(...) e deixou key de fora; é só um aviso, a tela ainda desenha, mas volta como bug silencioso quando a lista muda — o sintoma é o valor de um input ou uma animação ficar na linha errada. Dê um id estável dos seus dados. Usar o índice do array como key só é seguro numa lista cuja ordem nunca muda e onde nada é inserido ou removido no meio; caso contrário, reproduz quase exatamente o problema de não ter key. A partir do React 19 o Warning: inicial desapareceu.Too many re-renders. React limits the number of renders to prevent an infinite loop.Um render alterou o estado, esse estado disparou outro render, e o React cortou o ciclo para evitar um infinito. Quase sempre é uma função chamada onde deveria ser passada: onClick={setOpen(true)} executa a cada render, e precisa ser onClick={() => setOpen(true)}. As outras formas comuns são alterar o estado direto no corpo do render, e um useEffect cuja lista de dependências contém o valor que ele mesmo atualiza. Mova as mudanças de estado para um handler de evento ou um useEffect, e se o valor pode ser calculado durante o render, questione se ele precisa ser estado.

Python18

Um traceback do Python divide a resposta em duas partes — a última linha diz o que deu errado e os quadros acima dizem onde — então ler só a última linha dá o nome e perde o lugar; e nos erros de valor ausente, como NoneType e KeyError, a causa quase sempre está num quadro acima daquele que quebrou.

ModuleNotFoundError: No module named 'requests'O Python percorreu todos os diretórios de sys.path e não achou nenhum módulo com esse nome. Ou ele nunca foi instalado, ou foi instalado para outro interpretador — dar pip install fora de um ambiente virtual e rodar dentro dele gera exatamente isso. Escrever python -m pip install instala no interpretador que você está realmente usando, e o desencontro acaba.error: externally-managed-environmentEste Python é do sistema operacional ou do Homebrew, e o pip se recusa a escrever nele (PEP 668). Você rodou pip install no interpretador do sistema; a mensagem está pedindo que você crie um ambiente virtual. --break-system-packages faz o que o nome diz e pode deixar arquivos gerenciados pelo apt quebrados, então crie um .venv e instale lá.ImportError: cannot import name 'User' from partially initialized module 'models' (most likely due to a circular import)Dois módulos importam um ao outro, então você pediu um nome a um módulo que está apenas metade carregado. Vem do formato A importa B e B importa A, e é comum logo depois de dividir um arquivo, quando uma anotação de tipo traz o import de volta. Troque from y import Thing por import y e use y.Thing dentro da função: a busca acontece depois e o ciclo deixa de atrapalhar.IndentationError: unexpected indentA linha está mais indentada que a anterior e nada acima abriu um bloco que justifique esse nível extra. Em geral você colou código que trouxe os próprios espaços, ou apagou uma linha if e deixou o corpo indentado sob nada. Remova o espaço inicial da linha apontada pelo erro; se não enxergar a diferença, imprima a linha com cat -A e os espaços e tabs aparecem.TabError: inconsistent use of tabs and spaces in indentationTabs e espaços estão misturados dentro de um mesmo bloco, então o Python não consegue decidir qual linha está mais profunda. Acontece ao colar de um editor que insere tabs, ou quando duas pessoas editam o mesmo arquivo com configurações diferentes; na tela as linhas parecem iguais, e você não vai achar isso a olho. python -m tabnanny app.py mostra os números das linhas problemáticas, e o resto é converter o arquivo todo para quatro espaços no editor.SyntaxError: invalid syntaxO parser não conseguiu formar uma instrução com o que achou ali, e a causa costuma estar na linha anterior à apontada, não nela. Parêntese ou aspa sem fechar, dois-pontos faltando ou o print "x" do Python 2 são as causas comuns — com parêntese aberto o parser segue por várias linhas antes de desistir. python -m py_compile app.py checa a sintaxe sem executar nada, e desde a 3.10 as mensagens são bem mais específicas, então atualizar o Python já ajuda no diagnóstico.TypeError: 'NoneType' object is not subscriptableO valor que você tentou indexar com [...] é None. Algo mais acima devolveu None em silêncio: um dict.get() com chave ausente, um re.match que não casou, ou uma função sem return no caminho executado. Em vez de proteger o ponto da falha, suba e descubra por que é None — um if que pula o None só empurra o mesmo erro para a linha seguinte.AttributeError: 'NoneType' object has no attribute 'get'O objeto à esquerda do ponto é None, então o atributo ou método pedido não existe. Tem a mesma raiz de nonetype-not-subscriptable e aparece principalmente quando você encadeia direto o resultado de uma função que devolve None ao falhar, como o find() do BeautifulSoup ou re.search(). Mostre primeiro o que aquela função estava procurando e, se não encontrar nada for um caso legítimo, trate esse ramo explicitamente.KeyError: 'name'A chave não está no dict, e o texto entre aspas é exatamente a chave procurada — comece por aí, porque em geral é erro de digitação, diferença de maiúsculas, ou uma resposta de API com formato diferente do que você imaginou. Se o valor for de fato opcional, d.get("name") devolve None e d.get("name", 0) fornece um padrão; mas usar .get num valor obrigatório troca o erro por um None que viaja pelo código e explode muito mais longe.IndexError: list index out of rangeVocê pediu uma posição que a lista não tem. Com tamanho n o último índice válido é n-1, então range(len(x) + 1) e x[len(x)] param sempre aqui, e x[0] numa lista vazia é o mesmo erro — comum quando um filtro ou split acima não deixou nada. Percorrer como for item in items: elimina essa classe de bug de vez, e quando você realmente precisa da posição, enumerate(items) a fornece.ValueError: invalid literal for int() with base 10: '3.5'Você passou a int() uma string que ele não consegue ler como número inteiro, e o texto entre aspas é essa string. Um ponto decimal como em '3.5', uma string vazia, uma entrada com quebra de linha no fim ou um separador de milhar como em '1,000' são as causas comuns. Para um decimal, int(float(s)) resolve em dois passos — mas descarta a parte fracionária em vez de arredondar — e para qualquer valor digitado por uma pessoa, envolver em try/except ValueError é a correção honesta.UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byteVocê leu um arquivo ou uma sequência de bytes como UTF-8 e encontrou um byte que o UTF-8 não permite; a mensagem indica a posição e o byte. Em geral o arquivo é cp1252 ou outra codificação antiga vinda do Windows, ou não é texto: uma imagem, um zip, ou dados gzip que você esqueceu de descomprimir. O certo é descobrir a codificação real e passá-la em encoding=; errors="replace" deixa a leitura terminar, mas troca esses bytes por interrogações, e o dado segue silenciosamente corrompido.ZeroDivisionError: division by zeroAlgo foi dividido por zero e, na prática, o divisor quase nunca é um zero literal: é uma contagem que deu zero. Código que tira média quando a lista ficou vazia, ou um filtro que não casou com nada, é a fonte clássica: passa nos seus dados de desenvolvimento e falha pela primeira vez em produção. Verifique o denominador antes de dividir e decida o que zero significa ali; devolver 0, devolver None ou deixar a exceção subir são três decisões diferentes, e cada uma é correta em algum caso.RecursionError: maximum recursion depth exceededUma função chamou a si mesma mais fundo que o limite padrão de 1000 quadros. Muito mais vezes que um cálculo realmente profundo, isso quer dizer que a condição de parada está faltando ou nunca é atingida; recursão indireta também conta, como um __getattr__ ou uma property que lê o próprio atributo de novo. Ache os dois ou três quadros que se repetem no traceback e corrija primeiro o caso base. sys.setrecursionlimit() levanta o teto, mas deixa você estourar a pilha real do C, e aí o Python morre de vez em vez de levantar exceção — reescrever a recursão como laço é a resposta segura.UnboundLocalError: cannot access local variable 'count' where it is not associated with a valueSe uma função atribui a um nome em qualquer ponto do seu corpo, o Python trata esse nome como local à função — e você o leu antes de a atribuição rodar. Aparece quando você esperava ver o valor de fora com o mesmo nome, ou na primeira vez que escreve uma operação de leitura e escrita como count += 1. Inicializar dentro da função com count = 0 é a resposta comum; se precisar mesmo alterar o valor de módulo, global count faz isso, ao custo de um valor cujos escritores ficam difíceis de rastrear. Até a 3.10 o mesmo erro dizia 'local variable referenced before assignment'.TypeError: greet() takes 1 positional argument but 2 were givenVocê passou um argumento a mais do que a função aceita, e quando os números diferem em exatamente um é quase sempre o self. Definir um método dentro de uma classe como def greet(name): e chamar obj.greet("x") faz o Python enviar obj como primeiro argumento, o que dá dois. Se é um método, mude para def greet(self, name): para receber self; se ele não precisa da instância, marque com @staticmethod.PermissionError: [Errno 13] Permission deniedO sistema operacional recusou aquela operação naquele caminho. Você estava escrevendo em um lugar de outro dono, como /var/log ou /usr, ou em um volume montado num contêiner cujo UID não bate com o usuário do contêiner, ou — o caso que passa batido — você não tem permissão de escrita no diretório e não no arquivo, que é o que criar um arquivo novo exige. Veja dono e modo com ls -ld primeiro e, antes de apelar para sudo, pense em mover o caminho para onde você pode escrever: um arquivo criado sob sudo dá o mesmo erro na próxima vez que você abri-lo sem sudo.OSError: [Errno 98] Address already in useO bind falhou porque outro processo já ocupa aquela porta. Ou o servidor anterior não morreu de verdade, ou um recarregador automático subiu duas cópias, ou um contêiner Docker já publica a mesma porta. lsof -i :8000 mostra o PID que a mantém, para você limpar só aquele — leia o nome do processo antes de dar kill -9 em qualquer coisa. O errno muda por sistema: no Linux sai 98, no macOS sai 48.

Build e tipos10

Erros de build são uma ferramenta recusando antes de qualquer execução, então não quebram nada no momento em que aparecem — mas fazem duas perguntas: você vai corrigir o tipo ou o caminho para bater com a forma real, ou vai empurrar aquela linha com um as any ou um comentário de supressão? E é aqui que as coisas verdadeiras só na sua máquina — caixa das letras, extensões e variáveis de ambiente — aparecem pela primeira vez.

error TS2307: Cannot find module 'lodash' or its corresponding type declarations.O tsc não achou nem o módulo nem qualquer declaração de tipos para ele, e importa que a mensagem diga as duas coisas — o pacote pode estar ausente, ou instalado sem tipos. Se está instalado, o que falta são os tipos: npm i -D @types/lodash acrescenta o pacote companheiro, embora muitos pacotes modernos já tragam seus próprios tipos e não tenham @types. Quando isso aparece num import relativo, olhe a caixa das letras e as paths do tsconfig — um caminho para seus próprios arquivos não tem relação com @types.error TS2339: Property 'user' does not exist on type 'Request'.Aquele tipo não declara aquela propriedade. Vem de acrescentar um campo que o tipo da biblioteca não tem (pendurar user no Request do Express é o clássico), de um erro de digitação, ou de ler uma propriedade que existe em apenas um membro de uma união não estreitada. Corrigir o tipo para bater com a forma real é a resposta, e numa união, estreitar com 'x' in y ou um campo discriminante abre o acesso dentro do ramo. Calar com as any só amordaça o compilador: aquele ponto vai aceitar também um nome de propriedade escrito errado.error TS2345: Argument of type 'string' is not assignable to parameter of type 'number'.O tipo que a função aceita e o tipo que você passou são diferentes, e a mensagem os cita em ordem — primeiro o que você deu, depois o que ela queria. O caso mais comum de longe é um valor de campo de formulário, da query string de uma URL ou de JSON chegando como string onde se espera número. Converter uma vez na fronteira é a resposta, mas Number(value) devolve NaN em vez de lançar quando falha, então é preciso impedir que esse NaN siga viajando — Number.isFinite(n) é a checagem do lugar.error TS18048: 'user' is possibly 'undefined'.O valor pode ser undefined e você não tratou essa possibilidade; isto é o tsc pegando para você um futuro Cannot read properties of undefined. Aparece em campos opcionais, no resultado de um find() de array e em variáveis de ambiente que podem não estar definidas. A correção é decidir o que acontece quando falta: corte cedo com if (!user) return null, ou faça curto-circuito com user?.name. Calar como user!.name é declarar que você garante — e quando a garantia é falsa, volta como exceção em tempo de execução, sem nada da rede de segurança que uma verificação teria deixado.error TS7006: Parameter 'req' implicitly has an 'any' type.O parâmetro não tem tipo escrito e o tsc não tinha de onde inferir, então ele virou any implicitamente — e o noImplicitAny trata isso como erro. Aparece em arquivos vindos do JavaScript e quando um callback é extraído para a própria variável; já um callback escrito em linha como items.map(x => ...) tem contexto, o tsc infere e isto não dispara. Escrever o tipo ali é a correção. Você também pode escrever any explicitamente, mas isso é decidir desligar a checagem naquele parâmetro por inteiro — quando você não sabe o que é, unknown é mais honesto e obriga a estreitar antes de usar.Parsing error: Unexpected tokenO ESLint parou enquanto lia a sintaxe, antes de aplicar qualquer regra ao arquivo. Muito mais vezes que código realmente quebrado, isso quer dizer que o parser não conhece aquela sintaxe — um arquivo TypeScript lido pelo parser padrão, JSX que nunca foi habilitado, ou decorators e sintaxe muito nova entregues a um parser antigo. Rodar npx eslint --print-config app.ts naquele arquivo exato mostra qual parser e quais parserOptions realmente se aplicam, então comece por aí em vez de adivinhar. TypeScript precisa do @typescript-eslint/parser, e se o arquivo não deve ser verificado, colocá-lo em ignores é a resposta certa.You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file.Esta é a linha que o webpack acrescenta depois de Module parse failed, e quer dizer que ele tentou ler aquele arquivo como JavaScript e o arquivo não era JavaScript. Ou você importou algo que precisa de transformação — TypeScript, JSX, CSS, uma imagem, um arquivo .vue — sem nenhuma regra em module.rules, ou um pacote em node_modules publica fonte não compilada enquanto aquela pasta está no seu exclude. Acrescentar uma regra de loader para aquela extensão em module.rules é a correção, e o caminho impresso acima da mensagem diz qual arquivo travou. Apagar exclude: /node_modules/ para o erro sumir deixa todo o build bem mais lento; abrir exceção só para aquele pacote é a troca melhor.Failed to resolve import "./utils" from "src/main.ts". Does the file exist?Nada foi encontrado naquele caminho, e o "Does the file exist?" que ele imprime aponta para as três coisas que realmente vale checar: a caixa das letras, a extensão e qualquer alias em tsconfig ou vite.config. Os sistemas de arquivos do macOS e do Windows ignoram maiúsculas, então ./Utils funciona na sua máquina e quebra pela primeira vez na CI ou no deploy, onde o Linux se importa — este erro é a identidade mais comum de "mas na minha máquina funciona". git ls-files src | grep -i utils mostra a grafia que o repositório realmente guarda. Para um alias como @/utils, resolve.alias no vite.config e paths no tsconfig precisam concordar; corrija só um e o editor fica calado enquanto o build continua falhando.You're importing a component that needs useState. This React hook only works in a client component.No App Router todo componente é um componente de servidor por padrão, e um componente de servidor importou um arquivo que usa um hook que só faz sentido no navegador, como useState. A diretiva é uma única linha 'use client' no topo do arquivo, e acrescentá-la puxa aquele arquivo e tudo que ele importa para o pacote do cliente — por isso marcar o menor pedaço que precisa de estado, em vez da página inteira, é a escolha barata. No sentido oposto, dividir de forma que um componente de cliente receba componentes de servidor como filhos mantém a busca de dados no servidor. O Next.js 13 escrevia a mesma situação como "It only works in a Client Component but none of its parents are marked with \"use client\"".The engine "node" is incompatible with this module. Expected version ">=20"O pacote que você instala declara no campo engines as versões de Node que precisa, e a que você usa está fora dessa faixa. O Expected e o Got que vêm depois põem a exigência e a sua versão lado a lado, então essas duas linhas bastam — e se isso só acontece na CI, a versão de Node dela difere da sua máquina. Atualizar com nvm install 20 && nvm use 20 é a resposta direta, e escrever a mesma versão no .nvmrc e na configuração da CI evita que se separem outra vez. O --ignore-engines do yarn passa por cima, mas apaga o aviso em vez de criar compatibilidade: se o pacote usa sintaxe mais nova, ele falha em execução com um erro de sintaxe. O npm relata a mesma situação como aviso EBADENGINE e por padrão não bloqueia a instalação.

Docker12

Os erros do Docker só ficam legíveis quando você os coloca numa camada — o cliente que não alcança o daemon, o registro que te recusa, um RUN que falha durante o build e um contêiner que morre ao subir são quatro problemas diferentes — e nas camadas de build e execução a linha em si não é o motivo: o motivo está na saída do comando que rodava dentro, e o preço de cada correção também muda por camada.

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?O comando docker não faz nada sozinho: ele pede ao daemon por aquele socket, e ninguém respondeu. Ou o daemon não está rodando, ou o Docker Desktop ainda não terminou de subir no macOS ou Windows, ou no Linux seu usuário não está no grupo docker e não pode abrir o socket; os três casos dão esta mesma linha. No Linux suba com sudo systemctl start docker; com o Desktop, abra o aplicativo primeiro. Se for permissão, sudo usermod -aG docker $USER e um novo login resolvem — mas saiba que esse grupo equivale na prática a root.Bind for 0.0.0.0:8080 failed: port is already allocatedVocê pediu aquela porta do host com -p e outro contêiner ou processo já a ocupa. Na maioria das vezes um contêiner iniciado antes sem --rm continua lá, parado ou em execução, ou o compose ainda segura um contêiner antigo. docker ps --filter publish=8080 aponta direto para o contêiner que a publica; se for um programa comum do host e não um contêiner, lsof -i :8080 acha. Mudar só o lado do host, como -p 8081:80, destrava você, mas deixar o contêiner antigo no lugar garante a mesma colisão na próxima vez.Conflict. The container name "/api" is already in use by containerO nome que você passou com --name já pertence a outro contêiner. Nomes são únicos também entre os contêineres parados, não só os em execução, então normalmente um que morreu ontem ainda o segura — invisível no docker ps e visível apenas no docker ps -a. docker rm -f api libera o nome e junto destrói a camada de escrita daquele contêiner (volumes nomeados sobrevivem). Para um contêiner de uso único, subir com docker run --rm evita a situação por completo.failed to register layer: Error processing tar file(exit status 1): no space left on deviceNão há espaço no disco para descompactar a camada da imagem. Em geral o projeto não é grande: é o Docker que ainda guarda meses de imagens antigas, cache de build e volumes de contêineres que você removeu. docker system df mostra quanto está em imagens, contêineres, volumes e cache de build e quanto disso é recuperável, então leia isso antes de apagar qualquer coisa. docker system prune remove contêineres parados, imagens penduradas, redes sem uso e o cache de build — o próximo build fica visivelmente mais lento sem esse cache — e acrescentar --volumes apaga também os volumes não ligados a um contêiner, que é exatamente onde as pessoas perdem seus bancos de dados.pull access denied for myapp, repository does not exist or may require 'docker login'O registro não te mostrou aquele repositório, e o essencial é que a mensagem cobre duas causas ao mesmo tempo: o nome não existe, ou existe e você não tem permissão de vê-lo. Ou você não está autenticado para um repositório privado, ou falta o usuário/organização no nome (myapp e myorg/myapp são repositórios diferentes), ou o nome está errado. Se a imagem é privada, faça docker login naquele registro; se deveria ser pública, releia a grafia. Registros de propósito não distinguem "não existe" de "não pode", porque a existência de um nome já é informação.manifest for myapp:v2 not found: manifest unknownO repositório foi encontrado, mas a tag não está nele. Diferente de pull access denied, esta mensagem diz que o nome estava certo, então só resta checar a tag: uma tag apagada ou movida, um pipeline que subiu latest e nunca criou v2, ou uma tag sem imagem para a sua arquitetura. docker manifest inspect myapp:v2 confirma se a tag resolve e quais plataformas ela traz. Trocar para latest só para seguir custa um build que não pode ser reproduzido, então corrija a tag.unauthorized: incorrect username or passwordO registro recusou as credenciais enviadas. Mais frequente que uma senha digitada errado é uma senha enviada a um registro que já não aceita senha de conta — o Docker Hub só aceita access token quando o segundo fator está ligado, e os registros do GitHub e do GitLab sempre quiseram token ou deploy key. docker logout limpa a credencial guardada; depois faça docker login de novo com um token. Passá-lo como echo $TOKEN | docker login -u user --password-stdin mantém o token fora do histórico do shell.failed to solve: process "/bin/sh -c npm ci" did not complete successfully: exit code: 1Aquela linha RUN do seu Dockerfile terminou com status diferente de zero. Esta linha só diz qual comando falhou e com que código; o motivo real está na saída daquele comando, acima, que o BuildKit costuma recolher quando o passo termina. Rodar de novo com docker build --progress=plain imprime a saída completa de cada passo, e se uma camada em cache esconde uma falha antiga, acrescente --no-cache — ao custo de reconstruir tudo desde o primeiro passo. exit code: 1 não é um motivo, apenas o fato de o comando ter falhado.COPY failed: file not found in build context or excluded by .dockerignoreO COPY só pega arquivos de dentro do contexto de build, e o arquivo não está lá. O contexto é o último argumento do docker build, então normalmente você apontou para uma pasta acima com ../x, ou o .dockerignore filtrou o arquivo — clássico quando node_modules ou *.env está ignorado e depois se copia algo de dentro dele. A mensagem cita as duas causas, então leia cat .dockerignore primeiro e reescreva o caminho a partir da raiz do contexto. Alargar o contexto para resolver significa enviar a pasta inteira ao daemon, e todo build fica mais lento.exec /usr/local/bin/entrypoint.sh: exec format errorO kernel não reconheceu o cabeçalho daquele executável e, hoje, é quase sempre incompatibilidade de arquitetura — uma imagem arm64 construída no Apple Silicon rodando num host amd64, ou o contrário. Um script de shell sem a primeira linha #!/bin/sh produz o mesmo texto. Construir com docker build --platform=linux/amd64 é a resposta comum, mas não remove a incompatibilidade: encobre com emulação, e tudo que passa pelo QEMU fica várias vezes mais lento que o nativo. Para uma imagem que você vai manter, construir as duas arquiteturas com buildx é o caminho que não cobra nada em execução.standard_init_linux.go: exec user process caused: no such file or directoryO contêiner tentou executar seu entrypoint e o kernel respondeu "no such file" — e a armadilha é que o arquivo está claramente lá. As quebras de linha do script são CRLF, então a primeira linha é lida como #!/bin/sh\r e o kernel procura um interpretador chamado literalmente sh\r; clonar no Windows ou deixar o autocrlf do git ligado produz exatamente isso. dos2unix entrypoint.sh converte aquele arquivo (ou sed -i 's/\r$//' entrypoint.sh se não tiver), e uma linha *.sh text eol=lf no .gitattributes impede que volte. Citar no #! um interpretador que a imagem não tem — bash numa imagem alpine — dá o mesmo texto.OCI runtime create failed: exec: "bash": executable file not found in $PATH: unknownO contêiner foi criado, mas o programa que você pediu para executar não estava no $PATH dentro dele. Imagens baseadas em Alpine trazem sh e não bash, então docker run -it myapp bash ou um CMD ["bash", ...] termina exatamente neste erro — assim como qualquer ferramenta que você supôs estar na imagem e só existe no seu host. docker run --rm -it myapp sh te dá um shell para ver o que a imagem realmente contém. Se precisar mesmo de bash, RUN apk add --no-cache bash no Dockerfile adiciona, ao custo de uma imagem maior.

Como ler uma mensagem de erro

  • Leia da primeira linha para baixo. Quanto mais abaixo, mais são as tripas da ferramenta; a causa costuma estar no topo.
  • Se há arquivo e número de linha, comece ali — não o quadro superior da pilha, e sim a linha mais alta que nomeie um arquivo seu.
  • Pesquise a mensagem literal, mas tire primeiro seus caminhos e nomes de variáveis: é isso que impede a busca de casar.
  • A mesma condição é redigida de formas diferentes conforme a versão. Se os resultados não batem, some o número da versão.
  • Antes de colar uma correção, veja o que ela descarta. Algumas não dá para desfazer.

Perguntas frequentes

Q. Por que as mensagens não são traduzidas?

Porque você vai pesquisá-las. A ferramenta imprime em inglês, e uma mensagem traduzida não acha nada. Só o sentido e a solução acompanham o idioma.

Q. Na minha tela está escrito um pouco diferente.

As ferramentas reescrevem isso entre versões. Se o esqueleto casa depois de tirar seus caminhos e nomes, é o mesmo erro. Se a versão difere, some o número à busca.

Q. Posso simplesmente rodar a correção?

Veja antes o que ela descarta. git reset --hard, um force push e docker system prune removem coisas que não voltam — as fichas avisam quando é o caso.

Q. Como procuro um erro que não está aqui?

Tire da mensagem seus caminhos, nomes e números e pesquise o que sobrar. Esse resto é a frase que os autores da ferramenta escreveram, e é o que casa.