Next.js, trasa /peru i porządki w GitHub Actions
Dzisiejszy dzień to głównie drobne poprawki, ale każda z nich usuwa realne tarcie. Dwie rzeczy warte opisania: próba wystawienia trasy /peru z portfolio i porządki w łańcuchu CI oraz QA, które wcześniej generowało puste artefakty i ostrzeżenia.
Problem: Trasa, która nie chciała działać, i cicha praca w CI
Pierwszy problem był z pozoru trywialny. Chciałem, żeby portfolio serwowało adres /peru. W folderze public/ trzymałem katalog z plikiem index.html i zakładałem, że Next.js sam poda go pod /peru. Tak się jednak nie stało. Next nie robi directory-index z public/, więc link prowadził donikąd. To klasyczna pułapka: pliki statyczne działają, dopóki nie oczekujesz od nich zachowania routera.
Drugi wątek to higiena CI i QA. W logach pipeline'u wracały ostrzeżenia o Node 20 w akcjach GitHub Actions. Krok upload artefaktu z raportem QA nie miał czego zbierać, bo nie generowałem raportu w formacie HTML. W kodzie QA została nieużywana stała SLUG_RE, a lokalny pre-push hook dorzucał lint, którego nikt już nie potrzebował w tym miejscu. Każda z tych rzeczy osobno jest mała, razem tworzą szum, który maskuje prawdziwe błędy.
Co zrobiłem: kilka małych decyzji zamiast jednej dużej
1. Serwowanie /peru przez route, a potem świadomy revert
Najpierw obszedłem brak directory-index, wystawiając /peru przez route w Next.js. To zadziałało, ale po chwili przyszła refleksja: aplikacja peru żyje tylko na Vercel, więc duplikowanie jej w portfolio nie ma sensu. Zamiast trzymać obejście na siłę, usunąłem trasę z portfolio. Czasem najlepszym rozwiązaniem jest cofnięcie zmiany.
2. Żywsze opisy treści w peru
Przy okazji poprawiłem opisy parkingu KTW i logistyki ACI. Dotąd były techniczne i suche, a to treść o wyprawie, więc dostały więcej klimatu. Zmiana czysto treściowa, bez wpływu na kod, ale realnie poprawia odbiór aplikacji.
3. Reporter HTML w QA, żeby artefakt miał co zbierać
Włączyłem reporter HTML w testach. Wcześniej krok upload-artifact kończył się sukcesem, ale wrzucał pustkę, bo nie było pliku raportu. Teraz pipeline ma co publikować, a ja mam wgląd w wyniki QA bez grzebania w logach.
4. Bump akcji do v5 i v6 (runtime Node 24)
Podniosłem wersje akcji w workflow:
- uses: actions/checkout@v5
- uses: actions/setup-node@v5
- uses: actions/upload-artifact@v5
Część akcji poszła do v6. Sedno jest w tym, że nowsze wersje działają na runtime Node 24, więc ostrzeżenia o Node 20 zniknęły z logów. Nie zmieniło to logiki pipeline'u, tylko usunęło szum.
5. Porządki: SLUG_RE i pre-push hook
Usunąłem nieużywaną stałą SLUG_RE oraz pre-push hook z lintem. Martwy kod i zbędne hooki to koszt poznawczy: człowiek zastanawia się, po co to jest, zamiast czytać kod, który faktycznie działa.
Dlaczego to ważne (Use Case):
Każda z tych zmian oszczędza czas w codziennej pracy. Pusty artefakt QA oznaczał, że przy awarii testów nie miałem czym się podeprzeć. Ostrzeżenia o Node 20 w logach sprawiały, że łatwiej było przeoczyć realny problem, bo wzrok przyzwyczaja się do żółtych linijek. Martwy kod i pre-push hook to dodatkowe tarcie dla każdego, kto wchodzi w repozytorium. A świadomy revert trasy /peru to oszczędność: mniej duplikacji, mniej miejsc, w których aplikacja może się rozjechać między Vercel a portfolio.
Czego się nauczyłem:
- Next.js nie robi directory-index z
public/. Jeśli chcesz trasę, potrzebujesz route albo plik musisz obsłużyć inaczej. Wiedza na przyszłość, żeby nie tracić czasu na to samo. - Warto sprawdzać, czy krok uploadu artefaktu ma co zbierać. Zielony pipeline nie znaczy, że dane są kompletne.
- Cofnięcie zmiany to też decyzja inżynierska. Kiedy aplikacja ma jedno źródło prawdy (u mnie Vercel), duplikowanie jej w portfolio tylko zwiększa ryzyko rozjazdu.
- Bump akcji do wyższego runtime to najprostszy sposób na wyciszenie deprecation warnings. Zero zmian w logice, mniej szumu w logach.