JS JavaScript · 30 вопросов · ~85 мин · ⏱ Таймер 25:00 · Сложный ·

Пакеты, npm и цепочка поставки

Профессиональный тест о package.json, семантических версиях, lock-файлах и рисках зависимостей. Задания требуют отличать диапазон от установленного дерева, понимать npm ci, оценивать install scripts и разбирать обновление не по одному числу severity, а по достижимости и последствиям.

Отвечено: 0 из 30

⏱ --:--

💡 Инструкция: Выберите один ответ из пяти. В тесте 30 вопросов и 85 минут; код лучше читать построчно, не полагаясь на первое впечатление. После завершения откроются общий процент, 6 тематических шкал и объяснение каждого решения.

Вопрос 1 из 30

Где должна находиться библиотека, импортируемая сервером в рабочем запуске?

{"dependencies":{"fastify":"^5.0.0"},"devDependencies":{"eslint":"^9.0.0"}}

Только devDependencies scripts peerDependencies всегда dependencies engines

Вопрос 2 из 30

Что делает поле private: true в корневом приложении?

{"name":"internal-app","private":true}

Предотвращает случайную публикацию пакета в npm Скрывает зависимости от audit Запрещает import Шифрует исходники Делает репозиторий закрытым

Вопрос 3 из 30

Зачем библиотеке peerDependencies для framework?

{"peerDependencies":{"react":"^19.0.0"}}

Чтобы запускать postinstall при каждом импорте библиотеки Чтобы установить внутри библиотеки две независимые копии framework Чтобы заменить карту публичных exports пакета Чтобы объявить диапазон framework, предоставляемого приложением Чтобы отключить правила SemVer для всех связанных пакетов

Вопрос 4 из 30

Что даёт exports?

Список переменных окружения Помогает сборщику удалить любой импортированный модуль Lock транзитивных версий Права ОС Явную карту публичных точек входа и условий импорта

Вопрос 5 из 30

Является ли engines.node жёсткой защитой выполнения во всех установках?

Ограничение действует только в браузере, но не в Node.js Поле автоматически удаляет неподходящую версию Node.js Да, любая установка прекращается при малейшем несовпадении Поле выбирает npm registry для нужной версии среды Обычно это декларация или warning, если менеджер не настроен строго

Вопрос 6 из 30

Какие обновления разрешает каретка в записи зависимости ^2.3.4?

{"dependencies":{"lib":"^2.3.4"}}

Любую 3.x Только prerelease Только 2.3.4 >=2.3.4 и <3.0.0 >=2.3.4 и <2.4.0

Вопрос 7 из 30

До какой версии может обновиться библиотека при тильде ~2.3.4?

{"dependencies":{"lib":"~2.3.4"}}

Только 2.3.4 Любую 2.x до 2.9 >=2.3.4 и <2.4.0 Только 2.4.0 >=2.3.4 и <3.0.0

Вопрос 8 из 30

Какой релиз соответствует исправлению совместимого дефекта в стабильном 4.2.1?

// Было 4.2.1; исправлена ошибка без изменения публичного API.

4.2.2 4.3.0 3.9.9 5.0.0 4.2.1-beta.1

Вопрос 9 из 30

Почему ^0.2.3 уже, чем ^2.3.0?

Для 0.x minor часто является границей совместимости, и ^0.2.3 не берёт 0.3 Caret полностью игнорирует все нулевые компоненты версии Стандарт SemVer не допускает версии с нулевым major Любая версия 0.x автоматически считается тегом latest Нулевой major запрещает выпускать исправления patch

Вопрос 10 из 30

Будет ли 2.4.0-beta.1 автоматически подходить обычному ^2.3.0?

Только на Windows Да, prerelease всегда выше Обычно нет без явного включения prerelease-диапазоном Да, если lock отсутствует Зависит от имени пакета

Вопрос 11 из 30

Что делает npm ci при расхождении package.json и package-lock.json?

npm ci

Обновляет lock и продолжает Игнорирует package.json Завершается ошибкой Удаляет зависимости из manifest Публикует пакет

Вопрос 12 из 30

Зачем коммитить package-lock приложения?

git diff -- package-lock.json

Чтобы хранить установленный каталог node_modules прямо в Git Чтобы package-lock полностью заменил package.json приложения Чтобы запретить npm обращаться к настроенному registry Чтобы скрыть лицензии транзитивных пакетов от проверяющих Чтобы зафиксировать дерево, integrity и воспроизводимую установку

Вопрос 13 из 30

Почему npm install может изменить lock?

npm install

Lock-файл используется только Yarn, а npm всегда создаёт новый Изменение lock вызвано политикой CORS пакетного registry При изменении manifest или рассинхронизации npm заново разрешает дерево Node.js переписывает исходники пакетов при каждой установке npm случайным образом переставляет поля JSON при любом запуске

Вопрос 14 из 30

Достаточно ли одинакового package.json для одинакового дерева без lock?

Да: любой диапазон SemVer всегда выбирает одну неизменную версию Нет: новые совместимые версии и транзитивные зависимости изменят дерево Различие возможно только для пакетов из devDependencies Да, если установка выполняется последней версией npm Да, если приложение использует ровно одну прямую зависимость

Вопрос 15 из 30

Что особенно проверить в подозрительном lock diff?

Источники resolved, integrity, версии и новые lifecycle-ветви Только изменение отступов и порядка полей package-lock.json Лишь общее число добавленных и удалённых строк diff Цветовую схему терминала, в котором был создан lock-файл Имя автора приложения и дату последнего локального коммита

Вопрос 16 из 30

Почему postinstall стороннего пакета требует внимания?

{"scripts":{"postinstall":"node setup.js"}}

Операционная система всегда проверяет цифровую подпись такого скрипта Скрипт запускается после установки, но получает доступ лишь к каталогу самого пакета Это исполняемый код с правами разработчика или среды CI Скрипт установки не имеет доступа к файлам и переменным среды Поле postinstall может содержать только текстовое описание

Вопрос 17 из 30

Как снизить риск typosquatting?

npm install lodahs

Вводить название быстрее, не сверяя похожие символы и scope Устанавливать пакет через sudo, чтобы избежать ошибки имени Выбирать только короткие названия, поскольку их труднее подделать Удалить lock-файл и разрешить registry выбрать другой пакет Сверить точное имя, scope, владельца, репозиторий и страницу пакета

Вопрос 18 из 30

Что означает npm audit report сам по себе?

npm audit --json > audit.json

Полный аудит исходников приложения и его бизнес-логики Совпадение известной уязвимости с деревом; достижимость ещё проверяют Доказательство, что найденная уязвимость достижима именно в приложении Гарантию, что в дереве нет неизвестных или будущих уязвимостей Автоматическую установку всех доступных безопасных обновлений

Вопрос 19 из 30

Почему npm audit fix --force опасен без проверки?

npm audit fix --force

После запуска открывается браузер со страницей рекомендации Команда может выйти за диапазоны и принести несовместимый major Флаг force удаляет сам npm после завершения исправления В этом режиме npm только печатает отчёт, не устанавливая пакеты Команда меняет package.json, но принципиально не трогает lock

Вопрос 20 из 30

Почему пакет из одной тривиальной функции тоже имеет цену?

npm принципиально не кэширует пакеты, состоящие из одной функции Функции нельзя распространять как отдельные пакеты npm Любой новый пакет увеличивает установленное дерево минимум на гигабайт Появляются издатель, обновления, транзитивные связи и install-код Установка маленького пакета изменяет семантику самого JavaScript

Вопрос 21 из 30

Как узнать, почему транзитивный пакет установлен?

npm ___ minimatch

npm explain package-name npm init package-name node --inspect package-name git blame package.json только npm publish package-name

Вопрос 22 из 30

Почему у разработчика и CI разные зависимости при наличии lock?

node --version
npm --version
npm config get registry
npm ci

Различались npm, registry, флаги или CI не использовал npm ci Lock-файл никогда не участвует в выборе установленных версий Операционная система всегда заменяет выбранную версию на другой major Git изменяет диапазоны SemVer при переносе package-lock между ветками Node.js случайным образом удаляет часть пакетов перед запуском CI

Вопрос 23 из 30

Что означает peer dependency conflict?

npm install

Имя пакета не удалось разрешить через DNS пакетного registry У одного из пакетов отсутствует файл README с описанием установки Пакеты требуют несовместимые диапазоны общей peer-зависимости Синтаксис package-lock повреждён и JSON не разбирается Пакет помечен private и поэтому не публикуется в публичный registry

Вопрос 24 из 30

Как безопаснее проверить обновление критической библиотеки?

Сразу выпускать latest, полагаясь на автоматическую совместимость Удалить старые тесты, если они не проходят после обновления Проверить только успешный код выхода команды npm install Считать любой minor-релиз безусловно совместимым без тестов Изолировать lock-diff и прогнать тесты, сборку и целевой smoke

Вопрос 25 из 30

Что собрать при 404 от private registry?

Registry для scope, безопасный способ auth, имя, версия и права Скриншот редактора без фактической конфигурации npm Полный .npmrc вместе с рабочим токеном доступа в журнале ошибки Только размер package-lock, чтобы оценить полноту установки Только сетевое имя компьютера, на котором возник ответ 404

Вопрос 26 из 30

Почему одна зависимость может сильно увеличить browser bundle, даже если её tarball мал?

import { tinyHelper } from "large-library";
// Проверить, что реально включил сборщик.

Пакет может тянуть тяжёлый runtime, полифилы и плохо удаляемый код Опубликованный tarball не содержит JavaScript-файлов библиотеки Каждая зависимость добавляет в клиентский bundle ровно один килобайт Сборщик включает README пакета в исполняемую клиентскую часть npm разжимает tarball так, что код всегда становится меньше

Вопрос 27 из 30

Что может вызвать дублирование одной библиотеки в bundle?

npm ls shared-lib

Одинаковые совместимые диапазоны, которые менеджер успешно дедуплицировал Обычная минификация имён и пробелов после построения графа Само наличие package-lock рядом с исходным кодом приложения Несовместимые версии или разные пути импорта, не сведённые сборщиком Один статический import библиотеки из единственного модуля

Вопрос 28 из 30

Почему регулярные небольшие обновления легче редких огромных?

SemVer запрещает выпускать обновления с большим числом изменений Небольшие обновления гарантированно не содержат новых дефектов Меньше одновременных изменений — проще diff, тесты и поиск регрессии npm не умеет читать lock-файлы, которым больше нескольких месяцев Каждый patch-релиз обязательно уменьшает размер client bundle

Вопрос 29 из 30

Стоит ли насильно применять overrides до одной версии при несовместимых требованиях?

Да, overrides согласует несовместимые API на этапе установки Только после проверки совместимости, иначе клиент получит чужой API Никогда, даже если override нужен для достижимой security-проблемы Overrides влияет лишь на отчёт и не меняет установленное дерево Только когда принудительная версия ниже всех заявленных диапазонов

Вопрос 30 из 30

Как измерить холодную установку честнее?

Использовать чистую среду и lock, отдельно учитывая кэш и scripts Оценить скорость по визуальному числу зависимостей в package.json Измерить продолжительность команды npm --version Один раз запустить npm install поверх тёплого node_modules Сравнивать только размер файла package.json до установки

Ответьте на все 30 вопросов, чтобы получить результат

🔗 Встроить тест на свой сайт (iframe) ▼

Скопируйте код и вставьте в любое место на вашем сайте:

Также доступна прямая ссылка на embed-страницу