Особенности npm и хранение node_modules в git

Нельзя только потому что это не предусмотрено. То есть приняли решение не фиксировать.

В том же Bundler, который и был предтечей всех современных систем контроля зависимостей, Gemfile.lock именно и предназначен для полной фиксации всех зависимостей приложений, на всю глубину дерева зависимостей.

Типичный пример:

Из

source "https://rubygems.org"

group :jekyll do
  gem "jekyll"
  gem "json"
  gem "nokogiri"
  gem "redcarpet"
  gem "textpow", git: 'https://github.com/regru/textpow.git'
  gem "ultraviolet", git: 'https://github.com/regru/ultraviolet.git'
end

Получаем

➜  bem-guide git:(master) cat Gemfile.lock
GIT
  remote: https://github.com/regru/textpow.git
  revision: ff81fdebcc72baeed82d80dffd09a58d6aa9802f
  specs:
    textpow (1.3.1)
      plist (>= 3.0.1)

GIT
  remote: https://github.com/regru/ultraviolet.git
  revision: a507f9e422b4b870d3437751b8d2f054165e97de
  specs:
    ultraviolet (1.0.1)

GEM
  remote: https://rubygems.org/
  specs:
    classifier (1.3.3)
      fast-stemmer (>= 1.0.0)
    colorator (0.1)
    commander (4.1.3)
      highline (~> 1.6.11)
    directory_watcher (1.4.1)
    fast-stemmer (1.0.2)
    highline (1.6.19)
    jekyll (1.0.3)
      classifier (~> 1.3)
      colorator (~> 0.1)
      commander (~> 4.1.3)
      directory_watcher (~> 1.4.1)
      kramdown (~> 1.0.2)
      liquid (~> 2.3)
      maruku (~> 0.5)
      pygments.rb (~> 0.5.0)
      safe_yaml (~> 0.7.0)
    json (1.8.0)
    kramdown (1.0.2)
    liquid (2.5.0)
    maruku (0.6.1)
      syntax (>= 1.0.0)
    mini_portile (0.5.0)
    nokogiri (1.6.0)
      mini_portile (~> 0.5.0)
    plist (3.1.0)
    posix-spawn (0.3.6)
    pygments.rb (0.5.1)
      posix-spawn (~> 0.3.6)
      yajl-ruby (~> 1.1.0)
    redcarpet (2.3.0)
    safe_yaml (0.7.1)
    syntax (1.0.0)
    yajl-ruby (1.1.0)

PLATFORMS
  ruby

DEPENDENCIES
  jekyll
  json
  nokogiri
  redcarpet
  textpow!
  ultraviolet!

Ухты, не знал :)

Но тем не менее, в описании shrinkwrap есть:

If you wish to lock down the specific bytes included in a package, for example to have 100% confidence in being able to reproduce a deployment or build, then you ought to check your dependencies into source control, or pursue some other mechanism that can verify contents rather than versions.

Как минимум, потому что там встречаются бинарные модули.

Насколько я могу судить, на сáмом-то деле всё именно так и устроено.

Автор пакета не может опубликовать новую версию под старым номером совершенно случайно, потому что никто не наберёт случайно «npm publish --force» вместо простого «npm publish». (Это была бы не такая случайность, когда подбрасываешь монету и выпадает решка — а такая случайность, когда подбрасываешь монетку, а выпадает полуторатонный вилочный штабелеукладчик.) Если автор пакета вдруг команду «npm publish --force» набрал и запустил, то можно быть совершенно уверенным в том, что именно это он и имел в виду, то есть руководствовался некоторыми соображениями — скорее всего, совершенно разумными.

Поэтому вызывает понятное удивление то обстоятельство, что Роджерс сперва пишет «Как сообщество, мы должны распределять между собой часть интеграционного тестирования», а затем теми же руками сомневается в том, что автор пакета знает, что он делает. И в том же aml сомневается.

Впрочем, надо признаться, что в известной мере я сужу здесь по себе. Последний раз я «npm publish --force» запускал буквально сегодня утром — и хорошо знаю о себе, что у меня была на то веская причина: я изменил текст README, а больше ничего. И так как кто угодно (и когда угодно) может зайти на Гитхаб и прочесть там свежайший текст README, то не великá беда, если у кого-то в пакете README останется старым из-за того, что «npm update имяМодуля» не сработает без роста номера версии. С другой стороны, новым потребителям пакета (которые только-только ещё «npm install имяМодуля» набирают) неплохо бы иметь новую версию README в нём. Так что в этаком случае уместно подменить последнюю версию пакета, а не выпускать новую версию, которая только реестр npm засоряет.

Думаю, может быть наивно, что и у остальных авторов пакетов какие-нибудь подобные уважительные соображения имеются.