[karma-server]: TypeError: Não é possível ler a propriedade 'range' de undefined - Teste de unidade angular em ambiente de CI

Nov 09 2020

Nossos pipelines de CI / CD pararam de funcionar na tarefa de "teste de ng" e falham com a seguinte mensagem de erro:

[karma-server]: TypeError: Cannot read property 'range' of undefined
    at handleRangeHeaders (/builds/......../node_modules/webpack-dev-middleware/lib/util.js:131:21)
    at processRequest (/builds/......../node_modules/webpack-dev-middleware/lib/middleware.js:98:19)
    at ready (/builds/......./node_modules/webpack-dev-middleware/lib/util.js:53:12)
    at handleRequest (/builds/........../node_modules/webpack-dev-middleware/lib/util.js:182:5)
    at /builds/............/node_modules/webpack-dev-middleware/lib/middleware.js:64:7
    at new Promise (<anonymous>)
    at middleware (/builds/........../node_modules/webpack-dev-middleware/lib/middleware.js:63:12)

Adicionados pontos para subtrair alguns nomes de repo específicos

Nunca tivemos esse erro antes e funcionou bem antes. Também curiosamente, funciona perfeitamente quando o executo localmente. Mas quando os executores do GitLab o executam, ele falha. Qualquer ajuda seria apreciada. Obrigado!

Respostas

9 mvorisek Nov 10 2020 at 13:17

Foi capaz de descobrir. Estávamos usando o node: mais recente em nosso arquivo .gitlab-ci.yml e tudo o que estava puxando para baixo estava causando um problema. (Parecia ser a versão 15). Portanto, em vez de node: latest, definimos como node: 14.

1 Joran Nov 22 2020 at 09:23

Na verdade, é um problema com o karma no nó v15. Parece que (por enquanto) não será corrigido, então fazer o downgrade para a v14 é a solução:https://github.com/karma-runner/karma/issues/3571

1 Wael Dec 17 2020 at 10:21

Esse problema acontecerá se você usar o node: latest e também para o node: 14, porque isso acontece na v14.15.2. Conforme mencionado nas respostas acima, você deve usar o nó: 14.15.1 e o problema irá embora.

Heehaaw Dec 03 2020 at 14:33

Se você não deseja alterar sua nodeversão global , pode instalar uma versão local e executá-la. Dessa forma, você obterá controle absoluto sobre o que está executando, independentemente do sistema em que estiver executando.

yarn add node@^14.15.0 --dev
// package.json
{
  "scripts": {
    "test": "node_modules/node/bin/node node_modules/.bin/ng test"
  }
}

Espero que isto ajude um pouco! 🙂

Samuel Dec 17 2020 at 19:23

Para minha tranquilidade e porque adoro javascript (realmente não adoro), depurei o problema. Fiz downgrade para o nó 14.xe ainda tinha o problema. Esta é minha análise em 14.x

TL; DR

Adicione a configuração de proxies mencionada abaixo e pare de usar ../assetsem seus arquivos ao fazer referência a coisas. Comece com uma barra:/assets/MyResource.png

Post Mortem

Eu encontrei esse cara aqui , que forneceu alguns insights que não me ajudaram, mas recomendou modificar karma.conf.js para adicionar basicamente uma versão desta entrada:

proxies: {
  '/assets/': 'src/assets/',
},

Ele diz que o karma não carrega o recurso corretamente, etc. Lembrei-me que adicionei uma imagem no meu css como fundo. Eu pensei "js, você quase me pegou, você não está engasgando com uma imagem, não é?" . Eu comentei a linha css e funcionou. WTF o_0?

Então é hora de callstack novamente, ótimo. Depois de ver isso

\client\angular5-pusher\node_modules\webpack-dev-middleware\lib\util.jssaí em alguma linha em um intervalo ausente , dei a volta na pilha de chamadas e cheguei ao proxy.js. Infelizmente, Ievgen Yamamoto estava certo, mas por que não funcionou para mim?

Como a depuração de printf é o modo mais engraçado de encontrar bugs, recorri a colar console.log nas coisas.

Um dos pedidos que eu vi depois de furar um console.log(req);em \client\angular5-pusher\node_modules\karma\lib\middleware\proxy.js:98parecia estranho para mim. Era a própria imagem que já descobri ser o problema. Mas o pedido era estranho, o pedido apontava para o caminho /MyImage.png.

Eu olhei meu arquivo css e o código estava bem normal

background: url('../assets/MyImage.png') no-repeat left top;

ng serve trabalhei com isso e fui capaz de me maravilhar com meu maravilhoso MyImage.png

O problema era que de alguma forma eu copiei uma amostra do agular2 em que alguém estava fazendo referência a imagens de uma forma estúpida de "../assets". Enquanto funcionava bem no navegador, o karma condensou-o em "/MyImage.png", não encontrou um proxy para ele, desistiu de descobrir como carregá-lo e morreu.

A solução final foi parar de usar caminhos errados.

Solução

Use caminhos que começam com uma barra /

background: url('/assets/MyImage.png') no-repeat left top;

Isso funcionou. Olhando ao redor da web, as pessoas também estão usando 'assets / MyImage', mas isso sempre falha durante a compilação porque esse caminho não pode ser resolvido. Pode ser eu e todas as outras pessoas sem algumas habilidades angulares básicas, mas quem sabe.

Eu nem sei se isso vai funcionar de qualquer maneira quando for empurrado para a produção, mas ei.

Nota lateral: Usar a solução requer a string "proxies", que foi mencionada anteriormente.