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 dependencies peerDependencies всегда scripts engines

Вопрос 2 из 30

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

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

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

Вопрос 3 из 30

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

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

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

Вопрос 4 из 30

Что даёт exports?

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

Вопрос 5 из 30

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

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

Вопрос 6 из 30

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

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

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

Вопрос 7 из 30

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

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

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

Вопрос 8 из 30

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

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

3.9.9 5.0.0 4.2.1-beta.1 4.3.0 4.2.2

Вопрос 9 из 30

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

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

Вопрос 10 из 30

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

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

Вопрос 11 из 30

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

npm ci

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

Вопрос 12 из 30

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

git diff -- package-lock.json

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

Вопрос 13 из 30

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

npm install

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

Вопрос 14 из 30

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

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

Вопрос 15 из 30

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

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

Вопрос 16 из 30

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

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

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

Вопрос 17 из 30

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

npm install lodahs

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

Вопрос 18 из 30

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

npm audit --json > audit.json

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

Вопрос 19 из 30

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

npm audit fix --force

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

Вопрос 20 из 30

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

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

Вопрос 21 из 30

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

npm ___ minimatch

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

Вопрос 22 из 30

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

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

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

Вопрос 23 из 30

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

npm install

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

Вопрос 24 из 30

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

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

Вопрос 25 из 30

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

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

Вопрос 26 из 30

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

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

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

Вопрос 27 из 30

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

npm ls shared-lib

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

Вопрос 28 из 30

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

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

Вопрос 29 из 30

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

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

Вопрос 30 из 30

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

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

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

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

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

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