Co siedzi w Twoim package.json? Sprawdź zanim wrzucisz na produkcję
Twój `package.json` zaraz wyląduje w npm. Albo w CI. Albo zostanie wklejony do monorepo, którego nikt nie sprzątał od dwóch lat. Pytanie: czy ten plik jest w porządku? Czy nazwa jest poprawna, wersja zgodna z SemVer, czy nie masz tej samej paczki w `dependencies` i `devDependencies`, czy `"react": "*"` nie wyleci Ci jutro przy npm install.
Wklejasz cały plik do okienka. Walidator robi cztery rzeczy:
- sprawdza, czy to w ogóle poprawny JSON (najczęstszy błąd: przecinek po ostatnim polu);
- weryfikuje schemę npm: nazwa pasuje do zasad rejestru, wersja jest w formacie SemVer, root jest obiektem;
- rysuje graf skryptów: który skrypt wywołuje który (np. `build` woła `clean` i `compile`), żebyś od razu widział, co się stanie po `npm run release`;
- audytuje zależności: duplikaty między deps i devDeps, gwiazdki (`"*"`, `"latest"`), mieszanka stylów (`^` vs `~` vs wersje dokładne), brakujące peer-y.
Wszystko lokalnie w przeglądarce. Nic nie wychodzi na serwer, więc spokojnie możesz wkleić `package.json` z firmowego projektu, nazwy zaleznosci, prywatnych rejestrów ani nazw skryptów nikt poza Tobą nie zobaczy.
Jak używać
- Wklej cały `package.json` do dużego pola tekstowego na górze. Jeśli chcesz tylko zobaczyć, jak to działa, kliknij Wczytaj przykład, walidator załaduje przykładową paczkę z jednym celowo zostawionym problemem.
- Karta „Poprawność" od razu pokazuje wynik na zielono albo czerwono. Zielono = JSON się parsuje i schema npm jest spełniona. Czerwono = klikasz w listę błędów i widzisz konkretne linie do poprawy.
- Karta „Metadane" pokazuje nazwę, wersję, typ modułu (ESM albo CommonJS), licencję, repozytorium, w czytelnym formacie zamiast szukania po JSON-ie.
- Karta „Skrypty" rysuje graf: który skrypt wywołuje który. Widzisz `build` → `clean` + `compile` → `tsc`. To bezcenne przy odziedziczonym projekcie z 30 skryptami.
- Karta „Zależności" zlicza paczki w czterech sekcjach (deps / devDeps / peerDeps / optional) i pokazuje listę wykrytych problemów: duplikaty, gwiazdki, brakujące peer-y, mieszanka stylów wersji.
- Karta „Pola wymagane" to zielony lub żółty checklist: name, version, description, license, scripts, repository. Wiesz od razu, czego brakuje, żeby paczkę dało się opublikować w npm.
- Kliknij Sformatuj, jeśli wkleiłeś jednolinijkowy `package.json` i chcesz mieć czytelny output do skopiowania z powrotem.
Kiedy się przydaje
Pięć sytuacji, w których walidator oszczędza Ci godzinę debugowania CI:
- Przed pierwszym `npm publish`. Paczka idzie do npm po raz pierwszy. Walidator sprawdza, czy nazwa jest poprawna (zła znaki w nazwie = rejestr odrzuca), czy wersja jest w SemVer i czy masz licencję. Bez tego dowiesz się dopiero po `npm publish`, gdy publikacja padnie z błędem.
- Code review pull requesta z monorepo. Ktoś dodał paczkę. Wklejasz jej `package.json` do walidatora i od razu widzisz: **`"react": "*"` w deps**. Komentujesz w PR, zanim mergeujesz coś, co rozsypie się przy najbliższej aktualizacji.
- Audyt cudzego projektu, który masz przejąć. Bierzesz legacy projekt, w którym 47 skryptów wywołuje się nawzajem. Walidator rysuje graf, widzisz, że `release` wywołuje `build`, ten `compile`, ten `tsc`. Mapa drogowa zamiast czytania 47 linii po kolei.
- Sprawdzenie, czemu CI pada na `npm ci`. Build na CI nie chce przejść. Wklejasz `package.json` i widzisz: `pakiet-x` jest w deps i devDeps, lock-file gubi się, `npm ci` wybiera różne wersje. Walidator pokazuje to czerwoną kartą.
- Migracja z npm na pnpm albo yarn. Przed migracją wklejasz oba `package.json` (stary i nowy), sprawdzasz, czy peer dependencies są spójne, czy nie ma gwiazdek (pnpm jest mniej tolerancyjne) i czy skrypty się układają w sensowny graf.