Должен ли я зафиксировать файл пряжи `.pnp.js`? - PullRequest
0 голосов
/ 25 октября 2019

Пряжа включает в себя дополнительную функцию «Plug'n'Play» , которая перемещает node_modules из каталога проекта. При этом он создает файл .pnp.js со ссылками на различные пути зависимости на жестком диске.

Файл создается автоматически, имеет длину несколько тысяч строк и, по-видимому, ссылается на пути , относящиеся кмашина , которая работала yarn install.

Разве .pnp.js предназначен для передачи с остальным кодом? Я не могу найти никакой информации об этом, несмотря на то, что файл кажется бесполезным для фиксации. Что считается наилучшей практикой и почему?

1 Ответ

2 голосов
/ 25 октября 2019

Я нашел этот комментарий от Arcanis (ведущего сопровождающего Yarn) по вопросу, спрашивающему о том, что включать в .gitignore. Он может ответить на ваш вопрос:

  • .yarn/plugins и .yarn/releases содержат выпуски пряжи, используемые в текущем хранилище (как определено yarn set version). Вы захотите сохранить их версию (это предотвратит потенциальные проблемы, если, скажем, два инженера используют разные версии Yarn с разными функциями).

  • .yarn/unplugged, вероятно, всегда следует игнорировать, так какможет содержать собственные сборки

  • .yarn/build-state.yml, вероятно, также следует игнорировать, так как содержит информацию о сборке

    • Если по какой-то причине у вас версия unplugged, также может иметь смысл оставить build-state также
  • .yarn/cache может быть проигнорировано, но вам нужно будет запустить yarn install, чтобы восстановить его

  • .pnp.js (и потенциально .pnp.data.json) находятся в той же лодке, что и кеш. Добавьте его в свой репозиторий, если вы храните кэш в своем репозитории, и игнорируйте его в противном случае.

  • yarn.lock всегда должны храниться в вашем репозитории (, даже если вы разрабатываетебиблиотека )

Подведем итог:

Если вы используете нулевую установку:

.yarn/unplugged
.yarn/build-state.yml

Если вы не используете нулевую установку:

.yarn/*
!.yarn/releases
!.yarn/plugins
.pnp.*
...