Почему «npm install» меняет package-lock.json и добавляет tild или cap? - PullRequest
Новая
       64

Почему «npm install» меняет package-lock.json и добавляет tild или cap?

1 голос
/ 10 мая 2019

На моем компьютере установлена ​​npm версия 6. У меня есть следующий контент в package-lock.json: 

{
  "name": "Project",
  "version": "0.0.0",
  "lockfileVersion": 1,
  "requires": true,
  "dependencies": {
    "package1": {
      "version": "0.1.2"
    },
    "package2": {
      "version": "0.2.2"
    }
  }
}

Всякий раз, когда я запускаю npm install, он обновляет мой package-lock.json, и новый контакт выглядит так: 

{
  "name": "Project",
  "version": "0.0.0",
  "lockfileVersion": 1,
  "requires": true,
  "dependencies": {
    "package1": {
      "version": "^0.1.2"
    },
    "package2": {
      "version": "~0.2.2"
    }
  }
}

Я не собираюсь добавлять ~ tild или cap ^ в версию package-lock. Я даже не добавляю и не удаляю пакеты до npm install. Файл Lock очень большой, поэтому сложно сохранить изменения вручную.

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

1 Ответ

1 голос
/ 10 мая 2019

В соответствии с моим пониманием и тем, что я искал по этому вопросу, я могу сказать, что это (package-lock.json) поведение является рефакторингом, чтобы упростить отслеживание зависимостей, даже если получение больших различий в файлах различий между тем не идеально. package-lock.json должен быть инструментом и механизмом, который отвечает за поддержание целостности, поэтому доверие к нему неизбежно и необходимо.

Документация

package-lock.json описывает точное сгенерированное дерево, так что последующие установки могут генерировать идентичные деревья независимо от промежуточных обновлений зависимостей.

Например, package.json - это: 

...
  "glamor": "^2.10.00"
...

В package-lock есть ссылки на конкретные версии, например, https://registry.npmjs.org/glamor /-/glamor-2.20.40.tgz Изменение коснулось только формата требуемого описания. Это было: 

"requires": {
  "glamor": "2.20.40"
}
Became:

"requires": {
  "glamor": "^2.0.0"
}

Semver не был сломан (2.20.40 все еще соответствует ^ 2.0.0), и ссылки остались на месте Когда версия пакета обновлена, пакет все еще будет взят из файла ссылки (есть старая версия пакета) Чтобы обновить ссылку в файле блокировки, вы должны либо изменить package.json, либо сделать npm update. Для получения дополнительной информации npm выдает

Подробнее об этом:

Допустим, вы используете закрепленные версии зависимостей 'aaa', 'bbb' и 'ccc'. Допустим, каждый из них зависит от 'zzz' так:

ааа зависит от zzz@^1.0.0 bbb зависит от zzz@^1.1.0 ccc зависит от zzz@^1.0.1

т.е. все три из них зависят от диапазона zzz, а не от точной версии.

И скажем, последняя версия zzz - 1.5.0.

Как до, так и после этого изменения, совершенно очевидно, что разрешенная версия zzz должна быть 1.5.0, поэтому единственное различие заключается в том, как package-lock.json структурирован и документирует эту субзависимость.

Раньше файл блокировки показывал, что все три из них зависят от zzz@1.5.0, а разрешенная версия z - 1.5.0.

Теперь он документирует фактические «исходные» версии зависимостей (например, ^ 1.0.0, ^ 1.1.0 и т. Д.) Для каждой зависимости, но по-прежнему показывает разрешенную версию z как 1.5.0.

Затем рассмотрим, что произойдет, когда выйдет zzz@1.5.1:

До этого файл блокировки должен был обновляться с z@1.5.0 до z@1.5.1 во всех четырех местах.

Теперь файл блокировки должен обновить только разрешенную версию z до 1.5.1, в то время как зависимости могут сохранять ^ 1.0.0, ^ 1.1.0 и ^ 1.0.1, потому что они не изменились.

Как я упоминал ранее в потоке, вы все равно получаете одинаковые node_modules в обоих случаях. Преимущества нового подхода:

Вы увидите, что на самом деле требуют зависимости (например, диапазон, а не точная версия). раньше вы не могли сказать, действительно ли aaa требовал именно zzz@1.5.0 или вместо этого zzz@^1.0.0.

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

Кроме того, пряжа использует аналогичную концепцию с yarn.lock. например Вот пример, где @ sindresorhus / is закреплен, но его символ-зависимость, наблюдаемый не: 

"@sindresorhus/is@0.10.0":
  version "0.10.0"
  resolved "https://registry.yarnpkg.com/@sindresorhus/is/-/is-0.10.0.tgz#f42dd6a9d12cd79fa6f53b27cf5bea3a30d2cafa"
  dependencies:
    symbol-observable "^1.2.0"
...