[karma-server]: TypeError: Cannot read property „range” of undefined - Angular Unit Testing w środowisku CI

Question

Nasze potoki CI / CD przestały działać w zadaniu „ng test” i kończą się niepowodzeniem z następującym komunikatem o błędzie:

[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)

Dodano okresy, aby subskrybować niektóre określone nazwy repozytoriów

Nigdy wcześniej nie mieliśmy tego błędu i wcześniej działał dobrze. Co dziwne, działa idealnie, gdy uruchamiam go lokalnie. Ale kiedy runner GitLab go wykonuje, kończy się niepowodzeniem. Każda pomoc będzie mile widziana. Dzięki!

Answer 1

Byłem w stanie to rozgryźć. Używaliśmy node: najnowszy w naszym pliku .gitlab-ci.yml i cokolwiek to było powodowało problem. (Wyglądała na wersję 15). Więc zamiast node: latest, ustawiamy go na node: 14.

Answer 2

To rzeczywiście problem z karmą w węźle v15. Wygląda na to, że (na razie) nie zostanie to naprawione, więc rozwiązaniem jest przejście na wersję 14:https://github.com/karma-runner/karma/issues/3571

Answer 3

Ten problem wystąpi, jeśli używasz węzła: najnowszy, a także węzła: 14, ponieważ dzieje się tak w przypadku wersji 14.15.2. Jak wspomniano w powyższych odpowiedziach, powinieneś użyć node: 14.15.1, a problem zniknie.

Answer 4

Jeśli nie chcesz zmieniać nodewersji globalnej , możesz zainstalować wersję lokalną i uruchomić ją. W ten sposób uzyskasz pełną kontrolę nad tym, co uruchomisz, niezależnie od systemu, na którym pracujesz.

yarn add node@^14.15.0 --dev

// package.json
{
  "scripts": {
    "test": "node_modules/node/bin/node node_modules/.bin/ng test"
  }
}

Mam nadzieję, że to trochę pomoże! 🙂

Answer 5

Ze względu na mój spokój i ponieważ uwielbiam JavaScript (naprawdę nie), zdebugowałem problem. Zdegradowałem do węzła 14.x i nadal miałem problem. To jest moja analiza na 14.x.

TL; DR

Dodaj konfigurację proxy wymienioną poniżej i przestań używać ../assetsw swoich plikach podczas odwoływania się do rzeczy. Zacznij od ukośnika:/assets/MyResource.png

Post Mortem

Uważam, że ten facet tutaj , pod warunkiem, że pewien wgląd, który mi nie pomoże, ale zaleca się, aby zmodyfikować karma.conf.js dodać zasadzie wersję tego wpisu:

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

Mówi, że karma nie ładuje poprawnie zasobów itp. Przypomniało mi się, że jako tło dodałem jakiś obrazek w moim css. Pomyślałem "js, prawie mnie złapałeś, nie dusisz się obrazem, prawda?" . Skomentowałem linię css i zadziałało. WTF o_0?

Więc znowu czas callstack, świetnie. Po obejrzeniu tego

\client\angular5-pusher\node_modules\webpack-dev-middleware\lib\util.jswyszedłem na jakiejś linii z brakującym zakresem , przeszedłem w stosie wywołań i doszedłem do proxy.js. Niestety, Ievgen Yamamoto miał rację, ale dlaczego mi się to nie udało?

Ponieważ debugowanie printf jest najzabawniejszym sposobem znajdowania błędów, uciekłem się do wklejania do rzeczy console.log.

Jedna z próśb, które widziałem po włożeniu console.log(req);w, \client\angular5-pusher\node_modules\karma\lib\middleware\proxy.js:98wyglądała dziwnie. To był ten sam obraz, o którym już się przekonałem. Ale prośba była dziwna, prośba wskazywała na ścieżkę /MyImage.png.

Spojrzałem na mój plik css i kod był całkiem normalny

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

ng serve pracowałem z tym i mogłem podziwiać moje wspaniałe MyImage.png

Problem polegał na tym, że w jakiś sposób skopiowałem próbkę agular2, w której ktoś odwoływał się do obrazów w głupi sposób „../assets”. Pracując dobrze w przeglądarce, karma skondensowała go do "/MyImage.png", nie znalazła dla niego proxy, zrezygnowała z szukania sposobu jego załadowania i umarła.

Ostatnim rozwiązaniem było zaprzestanie używania złych ścieżek.

Rozwiązanie

Użyj ścieżek zaczynających się ukośnikiem /

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

To załatwiło sprawę. Rozglądając się po sieci, ludzie również używają `` asset / MyImage '', ale zawsze kończy się to niepowodzeniem podczas kompilacji, ponieważ tej ścieżki nie można rozwiązać. Mogę być ja i wszyscy inni ludzie, którym brakuje podstawowych umiejętności kątowych, ale kto wie.

Nie wiem nawet, czy to i tak zadziała, kiedy będę przechodził do produkcji, ale hej.

Uwaga: użycie tego rozwiązania wymaga napisu „proxy”, o którym była mowa wcześniej.