Sprawdź package.json tak, jak czyta go npm: nazwa, wersja, licencja, zależności i składnia
Działa w przeglądarce. Wpisane dane nie są nigdzie wysyłane. Sprawdzono 16 października 2026.Walidator package.json sprawdza plik, który npm czyta przed instalacją lub publikacją pakietu. Po wklejeniu pliku widać błędy składni JSON z numerem linii, dokładne ostrzeżenia wypisywane przez npm, czy nazwa jest dozwolona, czy licencja jest jednym z 734 identyfikatorów SPDX oraz wersje zależności, które nie są prawdziwymi zakresami.
Ta strona została przetłumaczona maszynowo z angielskiego oryginału. Tłumaczenie nie zostało jeszcze sprawdzone przez człowieka, dlatego wiążąca jest wersja angielska. Przeczytaj angielski oryginał
Wklej package.json, otwórz plik albo kliknij Wypróbuj przykład.
Najpierw popraw błędy składni JSON: widać linię i kolumnę oraz typową przyczynę.
Przeczytaj, co mówi npm: ostrzeżenia i błędy, które sam npm wypisuje dla tego pliku, słowo w słowo.
Przejdź przez dodatkowe kontrole, np. zależności bez przypiętej wersji, i kliknij Kopiuj raport, aby je udostępnić.
npm czyta package.json w niektórych miejscach ściśle, a w innych łagodnie: błędna wersja zatrzymuje wszystko, a brak opisu daje tylko ostrzeżenie. Ta strona sprawdza plik w trzech warstwach i pokazuje każdą osobno.
1. Składnia JSON. Pierwszy błąd jest pokazywany z linią, kolumną i typową przyczyną: końcowy przecinek, komentarz, pojedyncze cudzysłowy lub klucz bez cudzysłowów. Wymieniane są też zduplikowane klucze, bo JSON.parse po cichu zachowuje tylko ostatni, a pierwsza wartość ginie.
2. Co mówi npm. Ostrzeżenia i błędy, które sam npm wypisuje dla tego pliku, słowo w słowo, np. "No repository field." lub "Invalid version". Pochodzą z przepisania własnych modułów npm: normalize-package-data, validate-npm-package-name i validate-npm-package-license, a testy porównują odpowiedzi z tymi pakietami na 80 przykładowych plikach, 44 nazwach i 54 ciągach licencji.
| Komunikat npm | Co zrobić |
|---|---|
| Invalid version: "1.0" | Wpisz trzy liczby, np. 1.0.0 |
| No license field. | Dodaj "license": "MIT" lub inny identyfikator SPDX |
| license should be a valid SPDX license expression | Użyj dokładnego identyfikatora, np. Apache-2.0 |
| scripts['server'] should probably be scripts['start']. | Zmień nazwę skryptu na start |
| name can no longer contain capital letters | W nowym pakiecie użyj małych liter |
3. Dodatkowe kontrole. Zależności zapisane jako *, latest lub pusty ciąg; nieprawidłowe zakresy wersji, sprawdzane tymi samymi regułami co w npm; pakiet wymieniony jednocześnie w dependencies i devDependencies; zależności git bez tagu; ścieżki lokalne w publikowanym pakiecie; "type" inny niż module lub commonjs; zakresy engines; oraz zastępczy skrypt testowy pozostawiany przez npm init.
Plik oznaczony "private": true nigdy nie jest publikowany, więc npm nie wypisuje dla niego ostrzeżeń; strona o tym informuje. Wszystko działa w przeglądarce; nic z wklejonej treści nie jest nigdzie wysyłane.
Pole license musi zawierać dokładny identyfikator SPDX, np. MIT, ISC lub Apache-2.0, albo ich kombinację, np. (MIT OR Apache-2.0). Warianty bliskie, takie jak "mit", "Apache 2.0" czy "BSD", nie przechodzą. Dla kodu zamkniętego należy wpisać UNLICENSED lub SEE LICENSE IN LICENSE.txt, aby wskazać własny plik.
Nie w nowym pakiecie. Nazwy muszą być pisane małymi literami, mieć najwyżej 214 znaków, być bezpieczne dla URL, nie mogą zaczynać się od kropki ani podkreślenia i nie mogą być modułem rdzenia Node.js, takim jak http. Niektóre stare pakiety mają wielkie litery, bo reguły pojawiły się później, i npm nadal je instaluje, ale nowy taki pakiet odrzuca.
Wersja musi być pełną wersją semantyczną z trzema liczbami, np. 1.0.0 lub 2.1.0-beta.1. Wpisanie 1.0, latest lub pustego ciągu sprawia, że npm w ogóle nie odczyta pakietu. npm akceptuje początkowe v i je usuwa, więc v1.2.3 jest czytane jako 1.2.3.
Zwykle tak. Oba przyjmują dowolną wersję, więc dwie instalacje w odstępie miesiąca mogą dostać różne wersje główne z niezgodnymi zmianami. Lepiej wpisać zakres z daszkiem, np. ^4.17.21, który przyjmuje poprawki i nowe funkcje, ale zatrzymuje się przed kolejną wersją główną, i zatwierdzić plik blokady, aby każda instalacja była taka sama.
Nie. package.json to ścisły JSON, który nie ma komentarzy, więc linia z // lub /* uniemożliwia npm odczytanie pliku. Typowe obejście to klucz o nazwie "//" z wartością tekstową; npm ignoruje klucze, których nie zna. Kontrola składni na tej stronie wskazuje linię z komentarzem.
npm ostrzega, gdy package.json nie ma pola repository, bo strona npm na jego podstawie linkuje do kodu źródłowego. Należy dodać "repository": {"type": "git", "url": "git+https://github.com/user/repo.git"}. Ostrzeżenie niczego nie blokuje, a dla pakietu oznaczonego "private": true npm całkowicie je pomija.
Stawki i przepisy się zmieniają; przed oparciem się na danej liczbie należy sprawdzić źródło.
Nadal coś nie działa? Zapytaj o narzędzie Walidator package.json a odpowiedzieć może każdy, kto zna odpowiedź. Konto nie jest potrzebne.