Проверка package.json так, как его читает npm: имя, версия, лицензия, зависимости и синтаксис
Работает в вашем браузере. Ничего из того, что вы вводите, никуда не отправляется. Проверено 16 октября 2026 г..Валидатор package.json проверяет файл, который npm читает перед установкой или публикацией пакета. Вставьте файл и увидите синтаксические ошибки JSON с номером строки, точные предупреждения, которые выводит npm, допустимо ли имя, входит ли лицензия в 734 идентификатора SPDX, а также версии зависимостей, которые не являются настоящими диапазонами.
Эта страница переведена машинным способом с английского оригинала. Перевод ещё не проверен человеком, поэтому ориентируйтесь на английскую версию. Читать английский оригинал
Вставьте package.json, откройте файл или нажмите «Попробовать пример».
Сначала исправьте синтаксические ошибки JSON: показаны строка и столбец, а также обычная причина.
Прочитайте, что говорит npm: предупреждения и ошибки, которые сам npm выводит для этого файла, слово в слово.
Пройдите дополнительные проверки, например зависимости без закреплённых версий, и нажмите «Копировать отчёт», чтобы поделиться ими.
npm читает package.json в одних местах строго, а в других — мягко: неверная версия останавливает всё, а отсутствующее описание даёт лишь предупреждение. Эта страница проверяет файл в три слоя и показывает каждый отдельно.
1. Синтаксис JSON. Первая ошибка показывается со строкой, столбцом и обычной причиной: висящая запятая, комментарий, одинарные кавычки или ключ без кавычек. Повторяющиеся ключи тоже перечисляются, потому что JSON.parse молча оставляет только последний, и первое значение теряется.
2. Что говорит npm. Предупреждения и ошибки, которые сам npm выводит для этого файла, слово в слово, например "No repository field." или "Invalid version". Они получены переписыванием собственных модулей npm normalize-package-data, validate-npm-package-name и validate-npm-package-license, а тесты сравнивают ответы с этими пакетами на 80 примерах файлов, 44 именах и 54 строках лицензий.
| Сообщение npm | Что делать |
|---|---|
| Invalid version: "1.0" | Напишите три числа, например 1.0.0 |
| No license field. | Добавьте "license": "MIT" или другой идентификатор SPDX |
| license should be a valid SPDX license expression | Используйте точный идентификатор, например Apache-2.0 |
| scripts['server'] should probably be scripts['start']. | Переименуйте скрипт в start |
| name can no longer contain capital letters | Используйте строчные буквы для нового пакета |
3. Дополнительные проверки. Зависимости, записанные как *, latest или пустая строка; недопустимые диапазоны версий, проверенные по тем же правилам, что и в npm; пакет, указанный одновременно в dependencies и devDependencies; git-зависимости без тега; локальные пути в публикуемом пакете; "type", отличный от module или commonjs; диапазоны engines; и тестовый скрипт-заглушка, который оставляет npm init.
Файл с пометкой "private": true никогда не публикуется, поэтому npm не выводит для него предупреждения; страница об этом сообщает. Всё работает в вашем браузере; ничего из вставленного никуда не отправляется.
Поле license должно содержать точный идентификатор SPDX, например MIT, ISC или Apache-2.0, или их сочетание вроде (MIT OR Apache-2.0). Близкие варианты вроде "mit", "Apache 2.0" или "BSD" не проходят. Для закрытого кода пишите UNLICENSED или SEE LICENSE IN LICENSE.txt, чтобы сослаться на собственный файл.
Для нового пакета — нет. Имена должны быть в нижнем регистре, не длиннее 214 символов, безопасными для URL, не начинаться с точки или подчёркивания и не совпадать с модулем ядра Node.js, например http. У некоторых старых пакетов есть заглавные буквы, потому что правила появились позже, и npm их по-прежнему устанавливает, но новый такой пакет отклоняет.
Версия должна быть полной семантической версией из трёх чисел, например 1.0.0 или 2.1.0-beta.1. Если написать 1.0, latest или пустую строку, npm вообще не сможет прочитать пакет. npm принимает начальную v и убирает её, поэтому v1.2.3 читается как 1.2.3.
Обычно да. Оба варианта принимают любую версию, поэтому две установки с разницей в месяц могут получить разные мажорные версии с несовместимыми изменениями. Пишите диапазон с крышкой, например ^4.17.21: он принимает исправления и новые возможности, но останавливается перед следующей мажорной версией. И фиксируйте lock-файл в репозитории, чтобы все установки совпадали.
Нет. package.json — это строгий JSON, в котором нет комментариев, поэтому строка с // или /* не даёт npm прочитать файл. Распространённый обходной путь — ключ с именем "//" и строковым значением: npm игнорирует незнакомые ключи. Проверка синтаксиса на этой странице указывает на строку с комментарием.
npm предупреждает, когда в package.json нет поля repository, потому что сайт npm по нему ссылается на исходный код. Добавьте "repository": {"type": "git", "url": "git+https://github.com/user/repo.git"}. Предупреждение ничего не останавливает, а для пакета с пометкой "private": true npm его вовсе не выводит.
Ставки и правила меняются; проверьте источник, прежде чем полагаться на цифру.
Всё ещё не получается? Задайте вопрос об инструменте «Валидатор package.json» и ответить может любой, кто знает. Учётная запись не нужна.