다른 버전의 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

최신 웹팩은 이전 [email protected] 에 의존하는 이전 watchpack 에 의존합니다 .

chokidar 최신가에 따라 다르지만 [email protected]

그러나 npm 설치는 OS와 호환되지 않기 때문에 두 버전의 fsevent를 올바르게 건너 뛰었습니다.

하나:

 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 는 작동합니다. 내 환경 :

• 윈도우 10
• Nodejs 12.13.1
• npm 6.13.4

최신 노드로 업데이트 한 후 npm은 동일한 문제가 발생합니다. fsevent 인 모든 프로젝트는 fsevents를 빌드하기 때문에 npm ci 로 설치하지 못합니다.

• Windows 10 Pro 1909
• 노드 12.14.1
• npm 6.13.6

최신 노드로 업데이트 한 후 npm은 동일한 문제가 발생합니다. fsevent 인 모든 프로젝트는 fsevents를 빌드하기 때문에 npm ci 로 설치하지 못합니다.

* Windows 10 Pro 1909

* node 12.14.1

* npm 6.13.6

@padinko 추가 --no-optional 플래그 (예 : npm ci --no-optional 변형을 시도 했습니까? 차이가 있습니까?

최신 노드로 업데이트 한 후 npm은 동일한 문제가 발생합니다. fsevent 인 모든 프로젝트는 fsevents를 빌드하기 때문에 npm ci 로 설치하지 못합니다.

* 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 는 MacOS에만 설치해야하는 fsevents 를 설치합니다.

@mikemimik 또는 @isaacs ,이 버그에 대한 의견이 있습니까? 예, fsevents 는 이것이 이제 더 큰 문제인 이유를 변경했습니다. 그러나 근본적인 문제는 여전히 NPM으로 인해 발생하므로 여기서 해결해야합니다.

관련 변경 사항은 fsevents가 미리 컴파일 된 바이너리를 제자리에 빌드하는 대신 가져 오기 위해 node-pre-gyp을 사용하여 시작하여 모든 플랫폼에서 오류없이 종료되는 postinstall 스크립트를 생성 한 것 같습니다. npm ci 은 (는) 플랫폼 지원 여부를 확인하지 않고 잠금 파일에있는 모든 항목을 레이아웃하려고 시도하고 설치 스크립트가 실패한 선택적 dep 만 제거하므로이 dep를 설치하게됩니다.

npm v7에는이 문제가 없습니다. (지금이 작업을 수행 할 코드에서 작업 중입니다.) npm v6에서이 문제를 해결하는 것이 얼마나 관여하는지 확인하지 않았지만 "업그레이드"로 끝날 가능성이 높습니다. v7로 수정 ". 그동안 영향이 있다면 npm ci 대신 npm install 를 사용하는 것이 좋습니다.

예, fsevents 의 전술이 변경되었습니다. 그러나 실제로는 그 반대입니다. 그들은 미리 컴파일 된 바이너리를 가지고있었습니다. Windows에 설치하면 404가 표시되고 건너 뜁니다. 이제 빌드를 시도한 다음 빌드를 중단합니다. 빌드가 시작되지 않아야하기 때문입니다. 관계없이 : npm ci 은 CI 환경 용으로 설계되었습니다. 대신 npm i 를 어떻게 사용해야합니까? CI에서 엄격한 패키지 잠금 검사를 원합니다.

또한 : npm@7 가 LTS 이전에 노드 14에 착륙할까요? LTS 트랙에서 1 년 동안 npm i 또는 버전 잠금에 갇혀 있다고 가정하는 것이 맞습니까?

전술을 바꿔서 죄송합니다. 그러나 원래 사용했던 S3에 대한 액세스 권한을 잃었고 점점 더 심각한 보안 문제가되었습니다. 그래서 우리는 필요에 따라 다시 구축했습니다. 특히 NAPI 기반 v2.x는 노드 v8.x +에 대해 전혀 빌드 할 필요가 없습니다.

이제 빌드를 시도한 다음 빌드를 중단합니다. 빌드가 시작되지 않아야하기 때문입니다.

오, 이상하네요. npm ci 가 선택적 dep의 빌드 실패를 치명적이지 않은 경고 유형 이벤트로 처리하고 문제가되는 dep를 제거 할 것으로 예상합니다.

관계없이 : npm ci는 CI 환경을 위해 설계되었습니다. 왜 대신 npm i를 사용해야합니까? CI에서 엄격한 패키지 잠금 검사를 원합니다.

좋은 질문.

"CI 환경 용으로 설계됨"이 항상 "이 특정 애플리케이션에 대해이 특정 CI 환경에 가장 적합 함"을 의미하지는 않습니다.

이 경우 npm ci가 실행되는 두 가지 문제가 있습니다.

• 선택적 deps에 대한 빌드 실패를 제대로 처리하지 않습니다.
• os / cpu 제한을 기반으로 deps를 사전 필터링 할 수 없습니다. _only_ 정보가 추적되지 않는 package-lock.json을 확인하기 때문입니다. (즉,이 실패를 적절히 방지하는 데 필요한 정보가 포함 된 유일한 파일을 포함하여 일반적으로 불필요한 파일 읽기를 건너 뛰기 때문에 더 빠릅니다.)

그래서, 당신은 사용해야 npm i 보다는 npm ci 작동하기 때문에, 피를 모두 버그.

CI에서 엄격한 패키지 잠금 검사를 원합니다.

패키지 잠금이 신뢰할 수있는 무결성 및 해결 검사를 제공한다는 사실에 대해 이야기하고 있다면 좋은 소식이 있습니다. npm install 도 그렇게합니다.

package-lock 및 package.json이 서로 동기화되어 있는지 확인하는 경우 package.json에 "scripts": { "prepare": "npx lock-verify" } 를 추가 할 수 있습니다.

npm @ 7 이 LTS가되기 전에 노드 14에 도착할까요?

그것이 제 기대입니다.

그러나 LTS 인 경우에도 LTS 버전의 노드에서 LTS 버전의 npm을 사용하는 것이 LTS "고정 된"시간 범위 내에서 변경된다는 것을 의미하더라도 과거의 접근 방식은 npm v6을 4 개로 제공합니다. 몇 년은 Node가 할 것이라고 생각하지 않는 매우 나쁜 생각입니다. 그리고 npm은 런타임에 영향을주는 방식의 "종속성"이 아니라 실제로는 별도의 프로젝트이므로 일반적으로 괜찮습니다.

npm v7에는 몇 가지 주요 변경 사항이있을 것이므로 (가능한 한 최소화하려고 노력하고 있지만) 제 시간에 가져 오지 못하면 문제가 될 수 있거나 기본 구성을 설정하기 위해 약간의 양보를 할 수 있습니다. 노드 14 LTS와 함께 제공되는 npm v7이 npm v6에 최대한 가깝도록 다른 작업을 수행하십시오.

아, 방금 노드 일정 을 확인한 결과 시간이 했습니다 . Node 14의 _initial_ 릴리스는 3 개월 내에 있지만 10 월까지 LTS로 전환되지 않습니다.

그렇습니다. 우리는 명확해야합니다. npm v7의 초기 릴리스는 노드 14에 맞춰 사용할 수 있고 v14가 LTS에 도달 할 때까지 충분히 안정적 일 것으로 예상합니다. (유명한 마지막 말과 모든 것이지만 통합에 가까워짐에 따라 자신감이 꾸준히 높아지고 있으며 곧 바뀔 것이라고 생각할 이유가 없습니다.)

나는 이것이 버그보다 더 중요한 것으로 취급되지 않는다는 것에 놀랐습니다. 이것은 Windows의 빌드 서버에서 "npm ci"를 사용할 수 없도록 만드는 것입니다. 그것은 큰 문제입니다.

Windows뿐만 아니라 어떤 시스템에서도 npm ci를 사용할 수 없습니다.

패키지 잠금이 권위있는 무결성 및 해상도 검사를 제공한다는 사실에 대해 이야기하고 있다면 좋은 소식이 있습니다. npm install 도 마찬가지입니다.

잠깐만 요 .. package.json 파일에 설정된 규칙을 계속 준수하는 새 패키지를 사용할 수있는 경우 npm install 가 잠재적으로 package-lock.json 파일을 업데이트하는 것은 제 경험이었습니다.

이 기능이 @isaacs를 변경

@tommck 나는

package-lock 및 package.json이 서로 동기화되어 있는지 확인하는 경우 package.json에 "scripts": { "prepare": "npx lock-verify" } 을 추가 할 수 있습니다.

CI 환경에서 npm ci 의 가난한 사람의 구현으로 사용할 수 있다고 생각하십시오. npm install . 패키지 잠금이 여전히 package.json과 동기화되어 있는지 확인하는 준비 스크립트를 실행합니다.

내가 착각하지 않으면 두 가지 문제가 있습니다.

• 이것이 직접 종속성의 제약 조건을 충족하는 간접 종속성에 대한 업데이트를 처리하는 방법을 알지 못합니다. 업데이트되고 빌드에 최신 코드가 포함됩니다.
• lock-verify가 변경 사항을 감지하면 갑자기 실패한 빌드를 얻게됩니다. 업데이트 된 package-lock.json을 다시 생성하고 커밋해야합니다. 일부 종속성이 해제 될 때 실패하지 않고 내 빌드를 예측할 수 있기를 바랍니다.

그렇습니다. 이것은 큰 문제입니다. 운 좋게도 우리의 경우에는 Linux를 기반으로 빌드하고 패키지 조합에서 여전히 작동합니다. 다른 사람들은 운이 좋지 않습니다.

@coyoteecd 그래서 ... 잠금 파일이

"npm install"을 실행하면 여전히 새 종속성으로 패키지 잠금 파일을 수정할 수 있습니까?

틀 렸습니다. 그렇게하지 않습니다.

인수없이 npm install 를 실행하면 잠금 파일에있는 것과 다른 종속성이 추가되지 않습니다.

npm install 이 (가) npm ci 가 _하지 _ 않는 _하는 일은 node_modules 있고 이미 잠금 파일에있는 것과 일치하는 종속성을 _skip_ 다운로드하는 것입니다.

잠깐만 요 .. npm 설치로 인해 package.json 파일에 설정된 규칙을 계속 준수하는 새 패키지를 사용할 수있는 경우 잠재적으로 package-lock.json 파일이 업데이트되는 것은 내 경험이었습니다.

이 기능이 @isaacs를 변경

나는 그것이 일어나는 경우를보고 싶다. 잠금 파일을 존중하지 말라고 명시 적으로 지시하거나 npm update 를 실행하거나 잠금 파일이 유효하지 않은 경우 (즉, deps가 정의한 트리에서 종속성을 충족하지 않음) 잠금 파일은 npm install npm v5에 도입 된 이후로 계속됩니다.

full-icu 패키지는 가끔 잠금 파일을 변경하는 패키지입니다.하지만 npm이 아닌 그들의 문제라고 생각합니다.

내 경험 : 노드 v12가 있고 다른 개발자가 v10, 노드 v10에 대한 전체 icu 다운 그레이드 icu 데이터 패키지가있을 때 ..

모든 것을 잠그고 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 를 사용하도록 빌드 프로세스를 변경해야했습니다.

이것에 대한 업데이트가 있습니까? 또한이 버그의 영향을받습니다.

이것이 도움이되는지 확실하지 않지만 Linux에서 package-lock.json 가 이미 생성 된 패키지 (제 경우에는 WSL)에서 npm install 를 실행할 때이 문제가 발생했습니다. package-lock.json 삭제하고 Windows에서 npm install 을 다시 실행 한 후 괜찮 았습니다.

Serverless Pro CI가 npm 설치에서 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 나는 이것이 패키지의 OS 대상인이 스레드와 동일한 문제라고 생각하지 않습니다. 문제가없는 경우 별도의 문제를 제출할 수 있습니다.

아, 그런데 fsevents 는 5 월 5 일 이후로 더 이상이 문제가 발생하지 않습니다.
https://github.com/fsevents/fsevents/issues/301

@isaacs 이 땅이 npm@7 있었습니까?

@paulirwin 아마도 당신이 옳습니다. 내가 언급 한 문제에 대해 작성된 여러 문제와 포럼 게시물을 보았고이 문제로 인한 다운 스트림 문제라고 가정했습니다.

나는 그것이 일어나는 경우를보고 싶다. 잠금 파일을 존중하지 말라고 명시 적으로 지시하거나 npm update 를 실행하거나 잠금 파일이 유효하지 않은 경우 (즉, deps가 정의한 트리에서 종속성을 충족하지 않음) 잠금 파일은 npm install npm v5에 도입 된 이후로 계속됩니다.

패키지 버전이 태그로 지정 될 때 v6.14.8에서 유효한 잠금 파일로 npm install 업데이트 종속성을 보았습니다. # 2167로 기록되었습니다.

좋은 소식은 v7.0.10에서는 발생하지 않는 것 같습니다. : +1 :