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

Следующее на самом деле не применимо при написании повторно используемой библиотеки, которую вы собираетесь опубликовать в npm, поскольку вы, скорее всего, захотите проверить несколько версий Node.js.

Зачем это делать?

Прежде всего, может быть неясно, почему вы хотите полностью заблокировать это. Я столкнулся с несколькими причинами, почему в свое время:

  • Node.js изменяет/устаревает API-интерфейсы в основных версиях и иногда вводит новые API-интерфейсы в младших версиях, поэтому разработчики разных версий получают противоречивые результаты.
  • npm и Yarn иногда вводят новые версии файла блокировки, поэтому начинается игра в теннис файлов блокировки, когда разные разработчики в команде меняют его туда и обратно.
  • Мы должны стремиться к паритету с производством

Используйте менеджер версий

Обычный способ управления версиями в Node.js — через nvm. Вы добавляете файл .nvmrc с указанием используемой версии в корень вашего репозитория, а затем можете быстро переключиться на эту версию. Содержимое файла — это просто версия, которую вы хотите:

16.13.1

В вашем терминале при входе в каталог проекта вы можете сделать nvm use (или nvm install) и nvm подберет версию и переключится на нее.

Добавьте engines к своему package.json

Вы также можете добавить свою версию Node.js в объект engines в файле package.json.

"engines": {
  "node": "16.13.1",
  "npm": "^8"
},

Обратите внимание, как вы также можете применить версию npm. Обычно я просто устанавливаю его примерно на ту версию, которая поставляется с конкретной версией Node.js. Вы также можете сделать то же самое с yarn здесь, если это то, что вы используете.

Пряжа

Если на самом деле вы используете Yarn (я предпочитаю), то каждый раз, когда вы запускаете команду Yarn, она будет убеждаться, что ваша локальная версия Node.js удовлетворяет ограничениям. Если это несовместимая версия, она выдаст ошибку и сообщит вам, почему. Это здорово, потому что вероятность ошибки значительно снижается.

нпм

Если вы используете npm, это потребует немного больше работы и не будет таким хорошим. Вам нужно будет установить engine-strict на true в файле .npmrc:

engine-strict = true

Вы должны создать этот файл .npmrc в корне проекта, а не помещать его в тот, который находится в вашем пользовательском каталоге, чтобы он работал для всей команды.

Добавление этого сделает проверку npm только во время npm install. Если вы запустите что-нибудь еще, например npm start или npm run dev, проверка не будет выполнена.

Обслуживание

Теперь, когда у вас есть указанные версии, вы немного более защищены от ошибок и ловушек потенциального использования нескольких версий, упомянутых ранее. Если в течение дня вы переключаетесь между разными проектами, теперь у вас есть некоторая защита от подобных ошибок. Вы можете просто выполнить nvm use и перейти на соответствующую версию Node.js для проекта.

Если вы хотите протестировать новую версию, вы обычно можете выполнить поиск существующей версии (например, 16.13.1) и обновить ее до новой версии. Затем вы можете протестировать CI, развернуть его в тестовой среде и получить некоторую уверенность в том, что вы можете успешно выполнить обновление.

Идем дальше с Docker и Dev Containers

Некоторые команды будут использовать Docker, поэтому вероятность появления разных версий в команде будет меньше. Тем не менее, мне все еще нравится использовать функцию engines в package.json, показанную выше, поскольку она дает дополнительную защиту и, вероятно, будет вашей последней линией защиты.

Если вся команда использует Visual Studio Code, вы можете использовать контейнеры разработки. Это гарантирует, что у каждого разработчика будут одинаковые настройки независимо от используемой платформы. Они также очень полезны для адаптации новых членов команды.