Я столкнулся с той же проблемой с fsevents в Windows при установке двух пакетов, которые зависят от разных версий fsevents.

npm install chokidar --save

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})

+ [email protected]
added 14 packages from 17 contributors and audited 19 packages in 1.668s
found 0 vulnerabilities

npm install webpack --save-dev

npm WARN optional SKIPPING OPTIONAL DEPENDENCY: [email protected] (node_modules\watchpack\node_modules\fsevents):
npm WARN notsup SKIPPING OPTIONAL DEPENDENCY: Unsupported platform for [email protected]: wanted {"os":"darwin","arch":"any"} (current: {"os":"win32","arch":"x64"})

+ [email protected]
added 327 packages from 195 contributors and audited 4246 packages in 16.581s

Последний веб-пакет зависит от watchpack, который зависит от старого [email protected], который зависит от старого [email protected].

Хотя последний чокидар зависит от [email protected]

Но npm install правильно пропустил обе версии fsevents, поскольку они несовместимы с ОС.

Тем не мение:

 npm ci
npm WARN prepare removing existing node_modules/ before installation

> [email protected] install K:\SWS\test\node_modules\watchpack\node_modules\fsevents
> node-gyp rebuild


K:\SWS\test\node_modules\watchpack\node_modules\fsevents>if not defined npm_config_node_gyp (node "C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js" rebuild )
Traceback (most recent call last):
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\gyp_main.py", line 50, in <module>
    sys.exit(gyp.script_main())
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 554, in script_main
    return main(sys.argv[1:])
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 547, in main
    return gyp_main(args)
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\__init__.py", line 532, in gyp_main
    generator.GenerateOutput(flat_list, targets, data, params)
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\generator\msvs.py", line 2033, in GenerateOutput
    root_entries = _GatherSolutionFolders(
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\generator\msvs.py", line 1791, in _GatherSolutionFolders
    return _DictsToFolders('', root, flat)
  File "C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\gyp\pylib\gyp\generator\msvs.py", line 1744, in _DictsToFolders
    for folder, contents in bucket.items():
AttributeError: 'MSVSProject' object has no attribute 'items'
gyp ERR! configure error
gyp ERR! stack Error: `gyp` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onCpExit (C:\Program Files\nodejs\node_modules\npm\node_modules\node-gyp\lib\configure.js:351:16)
gyp ERR! stack     at ChildProcess.emit (events.js:210:5)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:272:12)
gyp ERR! System Windows_NT 10.0.17134
gyp ERR! command "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd K:\SWS\test\node_modules\watchpack\node_modules\fsevents
gyp ERR! node -v v12.14.0
gyp ERR! node-gyp -v v5.0.5
gyp ERR! not ok
added 275 packages in 9.344s

И если я посмотрю в node_modules, там есть fsevents, а этого быть не должно.
Кроме того, npm ci --no-optional не работает, об этом сообщается здесь: https://github.com/npm/cli/issues/637

Я использую установку Node 12 LTS, npm -v => 6.13.4

Работает ли npm ci --no-optional может зависеть от дополнительных факторов. См. Https://github.com/npm/cli/issues/637#issuecomment -570813804

Итак, хотя npm ci не работает в моей среде, npm ci --no-optional работает. Моя среда:

• Windows 10
• Nodejs 12.13.1
• нпм 6.13.4

После обновления до последней версии node и npm возникла такая же проблема ... все проекты, в которых используется fsevent, не могут быть установлены с npm ci , потому что он создает fsevents

• Windows 10 Pro 1909 г.
• узел 12.14.1
• ппм 6.13.6

После обновления до последней версии node и npm возникла такая же проблема ... все проекты, в которых используется fsevent, не могут быть установлены с npm ci , потому что он создает fsevents

* Windows 10 Pro 1909

* node 12.14.1

* npm 6.13.6

@padinko Вы тоже пробовали вариант с дополнительным флагом --no-optional , т.е. npm ci --no-optional ? Есть разница?

После обновления до последней версии node и npm возникла такая же проблема ... все проекты, в которых используется fsevent, не могут быть установлены с npm ci , потому что он создает fsevents

* Windows 10 Pro 1909

* node 12.14.1

* npm 6.13.6

@padinko Вы тоже пробовали вариант с дополнительным флагом --no-optional , т.е. npm ci --no-optional ? Есть разница?

npm ci не работают с этими пакетами:

\node_modules\watchpack\node_modules\fsevents
\node_modules\webpack-dev-server\node_modules\fsevents
\node_modules\jest-haste-map\node_modules\fsevents

npm ci --no-optional их всего 2:

\node_modules\webpack-dev-server\node_modules\fsevents
\node_modules\jest-haste-map\node_modules\fsevents

так что есть разница, но все же компиляция fsevents

@paulmillr @pipobscure Моя проблема (# 658) была дубликатом этой заявки. Следите за этим, чтобы оставаться в курсе.

Я могу подтвердить эту ошибку также на Ubuntu. npm ci устанавливает fsevents который должен быть установлен только на MacOS

@mikemimik или @isaacs , есть ли у вас какие-либо fsevents что-то изменило, поэтому теперь это большая проблема. Но основная проблема по-прежнему вызвана NPM и должна быть решена здесь.

Похоже, что соответствующее изменение заключается в том, что fsevents начали использовать node-pre-gyp для извлечения предварительно скомпилированного двоичного файла, а не для его сборки на месте, что привело к сценарию postinstall который завершается без ошибок на всех платформах. Поскольку npm ci просто пытается выложить все, что находится в файле блокировки, не проверяя, поддерживает ли он платформу, и удаляет только дополнительные deps, сценарии установки которых не работают, это приводит к установке этого dep.

npm v7 не будет иметь этой проблемы. (Я работаю над кодом, который сделает это сейчас.) Я не проверял, насколько это будет связано с исправлением этой проблемы для npm v6, но есть большая вероятность, что это будет просто «обновление до версии 7 для исправления ". А пока я бы рекомендовал использовать npm install вместо npm ci если это вас беспокоит.

Да, fsevents изменили свою тактику. Но на самом деле все наоборот. Раньше у них были предварительно скомпилированные двоичные файлы. Установка в Windows выдала бы 404 и пропустила. Теперь он пытается построить, а затем прерывает сборку. Потому что сборка даже не должна начинаться. В любом случае: npm ci предназначен для сред CI. Как же тогда использовать вместо этого npm i ? Нам нужны строгие проверки блокировки пакетов в CI.

Также: приземлится ли npm@7 в Node 14 вовремя, прежде чем это будет LTS? Правильно ли я предполагаю, что мы застряли с npm i или блокировкой версии на год, когда на треке LTS?

Извините, что изменил тактику в отношении вас. Однако мы потеряли доступ к S3, который использовался изначально, и это становилось все более серьезной проблемой безопасности. Вот почему мы возвращались к строительству по мере необходимости. Особенно учитывая, что v2.x на основе NAPI вообще не нужно собирать для node v8.x +

Теперь он пытается построить, а затем прерывает сборку. Потому что сборка даже не должна начинаться.

О, это странно. Я ожидал, что npm ci обработает сбой сборки из-за необязательного dep как событие нефатального типа предупреждения и просто удалит неправильный dep.

В любом случае: npm ci разработан для сред CI. Почему тогда мы должны использовать вместо этого npm i? Нам нужны строгие проверки блокировки пакетов в CI.

Хороший вопрос.

«Разработано для сред CI» не всегда означает «лучше всего для данной конкретной среды CI, для этого конкретного приложения».

В этом случае есть две проблемы, с которыми сталкивается npm ci.

• Он неправильно обрабатывает сбои сборки для дополнительных deps.
• Он не может предварительно фильтровать зависимости на основе ограничений os / cpu, потому что _only_ смотрит только на package-lock.json, где эта информация не отслеживается. (То есть это быстрее, потому что он пропускает чтение некоторых обычно ненужных файлов; включая, по ошибке, единственный файл, который содержит информацию, необходимую для того, чтобы должным образом избежать этого сбоя.)

Итак, вы должны использовать npm i вместо npm ci потому что это будет работать, избегая обеих ошибок.

Нам нужны строгие проверки блокировки пакетов в CI.

Если вы говорите о том, что пакетная блокировка обеспечивает авторитетные проверки целостности и разрешения, то хорошие новости: npm install тоже делает это.

Если вы говорите о проверке синхронизации package-lock и package.json друг с другом, вы можете добавить "scripts": { "prepare": "npx lock-verify" } в свой package.json.

Попадёт ли

Это мое ожидание, да.

Но, даже если это LTS, в прошлом подход заключался в том, чтобы иметь LTS-версию npm в LTS-версии узла, даже если это означает, что она изменяется в течение «замороженного» периода времени LTS, поэтому доставка npm v6 для 4 лет было бы очень плохой идеей, и я не думаю, что Node подойдет. И поскольку npm на самом деле является чем-то вроде отдельного проекта, а не «зависимостью», влияющей на время выполнения, обычно это нормально.

Так как npm v7 будет иметь некоторые критические изменения (хотя мы пытаемся минимизировать их в максимально возможной степени), это может быть проблемой, если мы не сделаем это вовремя, или мы можем сделать некоторые уступки, чтобы установить конфигурации по умолчанию или сделайте другие вещи, чтобы npm v7, поставляемый с узлом 14 LTS, был как можно ближе к npm v6.

О, я только что проверил расписание узла и увидел, что ошибся насчет таймфрейма. _Initial_ релиз Node 14 выйдет через 3 месяца, но он не станет LTS до октября.

Так что да, мы должны быть в порядке. Я ожидаю, что первоначальный выпуск npm v7 будет доступен ко времени для узла 14 и будет более чем достаточно стабильным к тому времени, когда v14 выйдет на LTS. (Знаменитые последние слова и все такое, но уверенность неуклонно растет по мере того, как мы приближаемся к выполнению интеграции, и у меня нет причин думать, что это скоро изменится.)

Я удивлен, что это не рассматривается как более важная ошибка, чем она есть. Это делает так, что мы не можем использовать "npm ci" на наших серверах сборки в Windows. Это большое дело.

Не только окна, я не могу использовать npm ci в любой системе

Если вы говорите о том, что блокировка пакета обеспечивает авторитетные проверки целостности и разрешения, то хорошие новости: npm install тоже делает это.

Подождите ... по моему опыту, npm install потенциально может привести к обновлению файла package-lock.json, если доступны новые пакеты, которые по-прежнему соответствуют правилам, установленным в файле package.json.

Изменилась ли эта функция @isaacs ?

@tommck Я думаю, он обращается к этому с помощью этой части:

Если вы говорите о проверке того, что package-lock и package.json синхронизированы друг с другом, вы можете добавить "scripts": { "prepare": "npx lock-verify" } в свой package.json.

Думаю, вы можете использовать его как плохую реализацию npm ci в вашей среде CI. Вы бы запустили npm install ; это запускает сценарий подготовки, который проверяет, синхронизирована ли по-прежнему блокировка пакета с вашим package.json.

Если не ошибаюсь, тут две проблемы:

• Я не понимаю, как это обрабатывает обновления косвенных зависимостей, которые удовлетворяют ограничениям ваших прямых зависимостей. Они будут обновлены, и ваша сборка будет включать новый код.
• Если lock-verify обнаруживает изменения, вы неожиданно получаете неудачную сборку. Вам придется повторно сгенерировать и зафиксировать обновленный package-lock.json. Я бы хотел, чтобы мои сборки были предсказуемыми, а не сбой при освобождении какой-либо зависимости.

Так что да, это большая проблема - к счастью, в нашем случае мы делаем сборки на linux, и они по-прежнему работают для нашей комбинации пакетов ... Другим людям повезло меньше.

@coyoteecd Итак ... при условии, что файл блокировки в порядке (правильный / проверенный), запуск "npm install" все равно может изменить файл блокировки пакета с новыми зависимостями?

запуск "npm install" все еще может изменить файл блокировки пакета с новыми зависимостями?

Неправильно. Этого не будет.

Запуск npm install без аргументов не приведет к добавлению каких-либо зависимостей, отличных от тех, что указаны в файле блокировки.

Что npm install будет делать, чего npm ci _не__ будет делать, - это _ пропустить_ загрузку зависимостей, которые находятся в node_modules и уже соответствуют тому, что находится в файле блокировки.

Подождите ... по моему опыту, установка npm потенциально может привести к обновлению файла package-lock.json, если доступны новые пакеты, которые все еще соответствуют правилам, установленным в файле package.json.

Изменилась ли эта функция @isaacs ?

Я бы хотел увидеть случай, когда это произойдет. Если вы явно не говорите ему не уважать файл блокировки, или запускаете npm update , или файл блокировки недействителен (т. Е. Зависимости не соответствуют зависимостям от дерева, которое он определяет), файл блокировки заблокировал npm install с момента его появления в npm v5.

full-icu - это пакет, который иногда меняет файл блокировки ... но я думаю, что это их проблема, а не npm

мой опыт: когда у вас есть узел v12, а у другого разработчика есть версия 10, пакет данных icu для перехода на полную версию icu понижается для узла v10 ..

когда у вас есть блокировка со всем и нет каталога node_modules и запускается npm i он удалит данные icu из файла блокировки, вам нужно запустить npm i второй раз, чтобы добавить его снова ..

мы использовали npm ci из-за этих двух проблем

Для всех, кто попадает сюда из-за fsevents , это решение npm ci из соответствующей проблемы:

https://github.com/fsevents/fsevents/issues/301#issuecomment -572607085

@jayoungers FWIW, это решение не сработало для меня. Каким-то образом другая версия fsevents все еще создается с npm ci . Мне пришлось изменить свои процессы сборки, чтобы вместо этого использовать npm i .

Есть ли обновления по этому поводу? Мы также подвержены этой ошибке.

Не уверен, что это помогает, но я столкнулся с этой проблемой при запуске npm install в пакете, где package-lock.json уже был сгенерирован в Linux (в моем случае WSL). После удаления package-lock.json и повторного запуска npm install в Windows все было в порядке.

Кажется, Serverless Pro CI изменен с npm install на npm ci, и эта проблема также возникает и нарушает сборку
Я совершаю с Windows-машины

build step: npm ci

> [email protected] postinstall /nuxt-serverless/node_modules/core-js
> node -e "try{require('./postinstall')}catch(e){}"


> [email protected] postinstall /nuxt-serverless/node_modules/ejs
> node ./postinstall.js


> [email protected] install /nuxt-serverless/node_modules/watchpack/node_modules/fsevents
> node-gyp rebuild

gyp
 ERR! build error 
gyp
 ERR! stack Error: not found: make
gyp ERR! stack     at getNotFoundError (/root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/which/which.js:13:12)
gyp
 ERR! stack     at F (/root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/which/which.js:68:19)
gyp ERR! stack
     at E (/root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/which/which.js:80:29)
gyp ERR! stack     at /root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/which/which.js:89:16
gyp ERR! 
stack     at /root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/isexe/index.js:42:5
gyp ERR! stack     at /root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/isexe/mode.js:8:5
gyp 
ERR! stack     at FSReqWrap.oncomplete (fs.js:154:21)
gyp ERR! 
System Linux 4.14.171-105.231.amzn1.x86_64
gyp ERR! command "/root/.nvm/versions/node/v10.13.0/bin/node" "/root/.nvm/versions/node/v10.13.0/lib/node_modules/npm/node_modules/node-gyp/bin/node-gyp.js" "rebuild"
gyp ERR! cwd /nuxt-serverless/node_modules/watchpack/node_modules/fsevents
gyp ERR!
 node -v v10.13.0
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok 

Использование npm install --no-optional не работает как обходной путь.

момент помечен как необязательный в package-lock.json :

"moment": {
      "version": "2.29.1",
      "resolved": "https://registry.npmjs.org/moment/-/moment-2.29.1.tgz",
      "integrity": "sha512-kHmoybcPV8Sqy59DwNDY3Jefr64lK/by/da0ViFcuA4DH0vQg5Q6Ze5VimxkfQNSC+Mls/Kx53s7TjP1RhFEDQ==",
      "dev": true,
      "optional": true
 }

Когда я удалю момент из node_modules, npm i вернет его:

rm -rf node_modules/moment
npm install --no-optional

ls node_modules | grep moment 
moment

@Elijen Я не верю, что это та же проблема, о которой идет речь в этой теме, а именно цели ОС для пакетов. Вы можете подать отдельную проблему, если такой проблемы еще нет.

Да, кстати, у fsevents больше нет этой проблемы с 5 мая:
https://github.com/fsevents/fsevents/issues/301

@isaacs Это приземлилось в npm@7 ?

@paulirwin Может ты и прав. Я видел несколько проблем и сообщений на форуме, посвященных упомянутой мной проблеме, и предположил, что это просто проблема, вызванная ею.

Я бы хотел увидеть случай, когда это произойдет. Если вы явно не говорите ему не уважать файл блокировки, или запускаете npm update , или файл блокировки недействителен (т. Е. Зависимости не соответствуют зависимостям от дерева, которое он определяет), файл блокировки заблокировал npm install с момента его появления в npm v5.

Я видел зависимости обновления npm install с допустимым файлом блокировки на v6.14.8, когда версии пакетов указываются тегом. Зарегистрирован как # 2167.

Хорошая новость заключается в том, что этого не происходит в версии 7.0.10: +1: