Gatsby: [fsevents 버그] MacOS에서 "소스 및 변환 노드"/ "createPagesStatefully"에서 멈춤

업데이트 됨-gatsby-node.js 파일에 대한 주석 처리를 테스트했으며 빌드가 한 번에 진행되었지만 다시 시도하고이 작업을 수행했는데 같은 위치에 다시 멈췄습니다.

이것이 내 오래된 컴퓨터 인 2010 Macbook Pro (8GB Ram 및 SSD로 업그레이드 됨) 때문일 가능성이 있습니까? 아직 저를 멈추지 않았지만 그 날이 제한되어 있다는 것을 알고 있습니다. 이것은 저에게 취미이고 어린 아이들이있어서 업그레이드 된 램과 SSD로 잘 작동했기 때문에 새 컴퓨터에 돈을 쓸 돈이 없었습니다.

나는 내가 안정된 마지막 버전 인 개츠비 2.13.52로 되돌리려 고 시도했고, 16.8.6에 반응하기 위해 되돌리려 고 시도했다.

흥미롭게도 나는 16.8.6으로 반응을 되 돌렸을 때 한 번 성공적으로 빌드했지만 그 후 처음으로 같은 지점에 끊겼는데 이는 나에게 정말 이상한 행동이었습니다.

나는 또한 드물게 아무 이유없이 잘 지을 수 있도록 분별할 수 있습니다. 이런 일이 발생했을 때 운율이나 이유가없는 것 같습니다. 이 문제를 일으킬 수있는 패턴이나 오류를 찾는 데 몇 시간을 보냈지 만 아무것도 찾지 못했습니다. 나는 https://github.com/gatsbyjs/gatsby/issues/6654를 검토하고 거기에있는 일부 항목을 시도했지만 아무 소용이 없었습니다.

이것은 코드에 눈에 띄는 변경이없이 동작이 변경되는 것처럼 보이기 때문에 내가 만난 가장 이상한 버그 중 하나입니다. 어떤 경우에는 빌드가 소스 및 변환 노드에서 중단되고 (시간의 60 %), 어떤 경우에는 Create Pages Statefully (20 %)에서 중단되고, 어떤 경우에는 성공적으로 빌드됩니다 (20 %). 코드 줄을 변경하지 않고 이러한 세 가지 동작을 모두 표시했습니다.

나는이 동작을 gatsby-starter-blog에서도 복제했는데, 정말 이상합니다. 다시 말하지만 이것이 내 쪽의 문제라고 생각하게 만듭니다. 흥미롭게도 createPagesStatefully 에만 매달립니다.

나는 이제 그것이 홈브류에 의해 자동으로 업데이트되는 라이브러리와 관련이 있다고 생각하기 시작했습니다. 내가 알지 못하지만 내가 테스트하지 않은 것은 내가 생각할 수있는 유일한 것입니다.

지금까지 시도한 작업 목록은 다음과 같습니다.

• 노드 버전 변경, 12, 10 및 8 시도

• 작동 중이던 커밋 기록의 이전 지점으로 되 돌리면 여전히 실패합니다.

• 플러그인 및 gatsby-config 영역 주석 처리

• 내 gatsby-node.js의 내용을 주석 처리

• Netlify에서 다시 테스트하고 성공적으로 구축되었으므로 내 컴퓨터와 관련이 있어야한다고 생각합니다.

• 내 src / pages 디렉토리에서 4 페이지를 삭제하고 매우 기본적인 index.mdx 파일에 넣습니다.

• 모든 node_module 및 잠금 파일 삭제, 재설치

• 컴퓨터 다시 시작

• Github에서 테마 / 스타터의 새로운 복제본으로 새로운 실 작업 공간을 만듭니다.

• gatsby-starter-blog 테스트, 유사한 동작이지만 createPagesStatefully 에서 멈춤

안녕하세요,

나는 거의 할 수 없지만 여러 개츠비 스타터 에서이 문제가 발생하고 있음을 확인합니다. 그리고 당신이 지적한 바와 같이, 때때로 "소스 및 변환 노드"또는 createPagesStatefully에 매달려 빌드하거나 빌드를 중지하기로 결정합니다.

매우 실망스럽고 그것을 고치기 위해 가장 터무니없는 시도를 시도합니다.

나는이 문제를 목격하지 못했지만 이것은 어색하게 들리며이 행동의 이유를 정말로 알고 싶습니다.

예비
노드 디버거를 사용하여 문제의 원인을 찾아야합니다. package.json의 작업은 다음과 같습니다. VSCode를 사용하는 경우 "자동 연결"을 활성화하여이 작업과 함께 내부 디버거를 사용할 수 있습니다 (이 목적으로 내부 터미널을 사용해야 함).

"start:debug": "node --inspect=127.0.0.1:9232 node_modules/.bin/gatsby develop",

물론 디버깅은 모든 IDE에서 작동합니다. 디버거를 올바르게 연결했는지 확인하기 만하면됩니다.

1. 변형 : 최소 생식
createPagesStatefully 을 문제의 원인으로 언급하셨습니다. 그것이 문제의 원인이라고 확신한다면 아주 작은 프로젝트를 만들어 재현 할 수 있습니다. 모든 스타터를 버리고 개츠비를 직접 사용하고 스타터가하는 일을 모방 한 몇 가지 예제와 함께 createPagesStatefully 에서 gatsby-node.js 사용하십시오. 그런 다음 gatsby를 시작하고 노드 검사를 통해 디버그합니다.

그렇게하면 어디에 매달려 있는지 찾을 수 있습니다.

2. 대안 : 프로젝트 / 스타터 내부
물론 동일한 기술을 사용하여 프로젝트 내에서 문제를 디버깅 할 수 있습니다. 그러나 아마도 당신은 문제의 원인에 대한 당신의 견해를 모호하게 만드는 여러 가지 문제가있을 수 있습니다. 그래서 나는 항상 디버그를 시작하기 전에 최소한의 재현을 얻으려고 노력할 것입니다.

행운을 빕니다.

그래서 ... 잠금 파일에 이상한 행동이 생겼습니다. 더 많은 것을 아는 사람이 나를 올바른 방향으로 안내 할 수 있습니다. 최소한의 작업 빌드를 얻으려는 과정에서 기본적으로 "hello world"Gatsby 설치를 제거했지만 여전히 작동하지 않았는데 정말 이상했습니다.

더 이상하게 된 곳은 실제 gatsby-starter-hello-world가 내 컴퓨터에서 잘 작동하고 잘 구축된다는 것입니다. 그러나 ... 잠금 파일을 삭제하고 얀이 새 잠금 파일을 다시 빌드하면 빌드가 실패하고 소스 및 변환 노드에서 중단됩니다. "hello-world"에서 잠금 파일을 복사하고 이것을 사용하면 빌드 할 최소한의 구현을 얻을 수 있습니다. 그래서 현재의 이론은 잠금 파일에이 문제를 일으키는 일종의 버전 문제가 있지만 여기에 갇혀 있다는 것입니다.

나는 또한 내 홈브류 설치를 모두 삭제하고 node, yarn, git 등을 다시 설치했습니다. 그저 재미있는 사업이 아닌지 확인하기 위해.

@ehowey 에게 감사드립니다 .... 꽤 간헐적이기 때문에 나 뿐이라고 생각했습니다 (하지만 시간의 50 % 이상이 발생합니다). 상황을 디버깅하기 위해 당신과 똑같이 했죠. ⠙ source and transform nodes 에 매달리면 일반적으로 터미널을 죽여야 함을 의미합니다.

내가 뭔가를 찾으면 알려 줄게. 그리고이 스레드도 볼 것입니다.

@georgiee--- inspect 정보에 감사드립니다. WebStorm으로 작업하는 노드 디버깅을 얻을 수 있는지 살펴 보겠습니다.

나는 또한 최소한의 재생산에 대한 당신의 생각을 좋아합니다. 하지만 제가 Gatsby를 좀 더 깊이 이해하는 데에는 시간이 걸립니다.

현재 "소스 및 변환 노드"에 매달려 있습니다. 드물게 createPagesStatefully로 만들고 거기에 멈 춥니 다. 그렇지 않으면 정상적으로 빌드됩니다.

취약한 종속성을 수정하기 위해 "yarn 업그레이드"를 수행 한 후에도 현재 동일한 문제에 직면하고 있습니다. 내 설정은 다음과 같습니다.

체계:
운영체제 : macOS 10.15
CPU : (4) x64 Intel (R) Core (TM) i7-7567U CPU @ 3.50GHz
셸 : 5.7.1-/ bin / zsh
바이너리 :
노드 : 12.8.1-/ usr / local / bin / node
원사 : 1.17.3-/ usr / local / bin / yarn
npm : 6.10.3-/ usr / local / bin / npm
언어 :
Python : 2.7.16-/ usr / local / bin / python
브라우저 :
크롬 : 76.0.3809.132
Firefox : 68.0.2
사파리 : 13.0
npm 패키지 :
개츠비 : ^ 2.13.42 => 2.14.7
개츠비 배경 이미지 : ^ 0.8.3 => 0.8.6
개츠비 이미지 : ^ 2.2.7 => 2.2.15
gatsby-plugin-manifest : ^ 2.2.4 => 2.2.10
gatsby-plugin-netlify : ^ 2.1.4 => 2.1.10
gatsby-plugin-netlify-cms : ^ 4.1.6 => 4.1.12
gatsby-plugin-offline : ^ 2.2.5 => 2.2.10
gatsby-plugin-react-helmet : ^ 3.1.2 => 3.1.5
gatsby-plugin-react-svg : ^ 2.1.1 => 2.1.2
gatsby-plugin-sass : ^ 2.1.3 => 2.1.12
gatsby-plugin-sharp : ^ 2.2.9 => 2.2.18
gatsby-plugin-typography : ^ 2.3.2 => 2.3.5
gatsby-plugin-webfonts : ^ 1.1.0 => 1.1.0
개츠비 발언 이미지 : ^ 3.1.10 => 3.1.19
개츠비 발언 상대 이미지 v2 : ^ 0.1.5 => 0.1.5
gatsby-remark-responsive-iframe : ^ 2.2.5 => 2.2.10
개츠비 소스 파일 시스템 : ^ 2.1.6 => 2.1.18
개츠비 변압기 발언 : ^ 2.6.12 => 2.6.19
개츠비-트랜스포머-샤프 : ^ 2.2.5 => 2.2.12

취약한 종속성을 수정하기 위해 "yarn 업그레이드"를 수행 한 후에도 현재 동일한 문제에 직면하고 있습니다. 내 설정은 다음과 같습니다.

업데이트 : 이전 "yarn.lock"파일을 복원하여 문제를 해결합니다.

뿡 빵뀨

업데이트 : 이전 "yarn.lock"파일을 복원하여 문제를 해결합니다.

내 경험에 따르면 나중에 다시 돌아올 명확한 이유없이 문제가 사라질 수 있습니다. yarn.lock을 복원 하였음에도 불구하고 반품에 문제가있을 수 있습니다. 우리에게 계속 알려줘.

다음은 gatsby-starter-hello-world를 사용한 최소 복제입니다.

https://github.com/ehowey/gatsby-test-lockfiles

리포지토리에 포함 된 현재 잠금 파일은 저에게 실패한 파일입니다. 또한 yarn-working.lock 및 yarn-notworking.lock 의 저장소에 사본을 포함했습니다. 누군가가 문제 해결을 더 쉽게 할 수 있기를 바랍니다.

내 현재 환경 :

체계:
운영체제 : macOS High Sierra 10.13.6
CPU : (2) x64 Intel (R) Core (TM) 2 Duo CPU P8600 @ 2.40GHz
셸 : 3.2.57-/ bin / bash
바이너리 :
노드 : 10.16.3-/ usr / local / bin / node
원사 : 1.17.3-/ usr / local / bin / yarn
npm : 6.10.3-/ usr / local / bin / npm
언어 :
Python : 2.7.10-/ usr / bin / python
브라우저 :
크롬 : 76.0.3809.132
Firefox : 67.0.2
Safari : 12.1.2
npm 패키지 :
개츠비 : ^ 2.13.73 => 2.15.0
npmGlobalPackages :
gatsby-cli : 2.7.40

동일한 문제가 발생합니다.

내가 찾은 방향 :

1. 그레이드 gatsby-plugin-sitemap 부터 2.2.9 로 2.2.6 가진 문제점을 해결 yarn develop .

   • gatsby-plugin-sitemap 가 개발 빌드에 영향을주지 않기 때문에 이상합니다.

2. yarn build 여전히 작동하지 않지만 구성에서 gatsby-plugin-sitemap 제거하면 yarn build 가 다시 작동합니다.

@sharvit 제 경우에는 이것이 작동하지 않았다고보고 할 수 있습니다. 그것이 당신을 위해 고쳐서 다행입니다. 궁극적으로 잠금 파일과 관련이 있다고 생각합니다. 잠금 파일의 내부 깊숙한 곳에 이상한 버전 문제가 있습니다.

이전 잠금 파일로 되돌리고 복사 및 붙여 넣기를 수행하여 대부분의 경우 작업 빌드로 돌아갈 수있었습니다. 이제 Ctrl + C를 눌러 빌드가 중단 된 경우 빌드를 강제 종료 할 수 있습니다.이 과정에서 한 지점에서 할 수 없었습니다. 잠금 파일에서 무엇이 수정되었는지는 모르겠지만 위에 게시 한 저장소에 잠금 파일 두 개 (작동하는 것과 작동하지 않는 복사본)가있는 것 같습니다. 이것은 벌레의 이상한 짐승입니다. 일반적으로 컴퓨터 영역에서는 일이 안심하고 작동하거나 작동하지 않습니다.

@steinitz 끝났어 ? 당신이 언급 한 일이 일어났습니다. 더 좋아지고 꽤 좋아 보였지만 완벽하지는 않았고 이제 거의 매번 실패하고 있습니다. 꽤 실망 스럽습니다.

헉

당신이 상상할 수 있듯이,이 문제의 반복적 인 특성 때문에 나는보고하는 것을 주저합니다. 다음은 적절한 사례입니다.

node_modules 디렉토리 삭제 후 yarn.lock 삭제 후 실행
npx yarn-upgrade-all
과
yarn install
모든게 괜찮 았어.

그런 다음 방금 귀하의 메시지에 응답하여
yarn start
결과 : 다시 멈춤
source and transform nodes

나는 두 가지 현명한 일이 있다고 생각합니다.

1. @georgiee 의 조언을 받아 Webstorm의 디버깅 작업을 수행하십시오.
   node --inspect 그리고 명백한 문제를 발견 할 수 있는지 확인
2. 똑똑한 사람이 문제를 해결하는지 확인하기 위해 Gatsby를 잠시 따로 두십시오.

최신 정보:

ctl-C'd 위의 멈춤 프로세스 (두 배로 성가신 멈춤 프로세스를 중지하는 데 사용되지 않음).
그런 다음 yarn start 은 (는) createPagesStatefully 에 붙어 있습니다.
ctl-C'd, 또 다른 yarn start - source and transform nodes 고정됨
ctl-C'd 한 번 더 (지옥을 위해)-이번에는 yarn start 작동했고 실행 중입니다.

무엇을 만들어야할지 모르겠지만 거기에 있습니다.

이것은 내가보고있는 것과 비슷합니다. 오늘 밤은 1/10 이하로 성공적으로 구축하는 것이 더 나빠 보입니다. 프로그래밍 / 코딩 관점에서 이것은 매우 이상한 행동입니다. 일화 적으로 며칠 전 2.15.1에서 오늘 2.15.6에서 더 잘 작동하는 것처럼 보였습니다. 나는 또한 우리 모두가이 버그를 발생시키는 공통점을 공유하고 있는지 궁금합니다. gatsby info --clipboard 명령을 실행하고 게시 할 수 있습니까?

분명히 널리 퍼져 있지는 않습니다. 그렇지 않으면 보고서가 넘쳐날 것이지만 원래 생각했던 것처럼 저 뿐만이 아닙니다. 우리는 모두 원사를 사용하는 것 같습니다. 제가 원사 작업 공간에서 테마를 작업 할 때 요구되는 사항입니다. 나는 여전히 이것을 gatsby-starter-hello-world에서 재현 할 수 있으므로 핵심 gatsby 파일의 종속성 문제 또는 충돌이라고 생각합니다.

@ehowey 는 요청하신 gatsby info

체계:
운영체제 : macOS 10.14.6
CPU : (4) x64 Intel (R) Core (TM) i7-5557U CPU @ 3.10GHz
셸 : 3.2.57-/ bin / bash
바이너리 :
노드 : 12.9.1-/ usr / local / bin / node
원사 : 1.17.3-/ usr / local / bin / yarn
npm : 6.11.2-/ usr / local / bin / npm
언어 :
Python : 2.7.16-/ usr / local / bin / python
브라우저 :
크롬 : 76.0.3809.132
Firefox : 68.0.1
Safari : 12.1.2
npm 패키지 :
개츠비 : ^ 2.14.3 => 2.14.7
개츠비 이미지 : ^ 2.2.14 => 2.2.15
개츠비 플러그인 피드 : ^ 2.3.9 => 2.3.9
gatsby-plugin-i18n : ^ 1.0.1 => 1.0.1
개츠비 플러그인리스 : ^ 3.0.2 => 3.0.4
gatsby-plugin-manifest : ^ 2.2.9 => 2.2.10
gatsby-plugin-offline : ^ 2.2.10 => 2.2.10
gatsby-plugin-react-helmet : ^ 3.1.5 => 3.1.5
gatsby-plugin-robots-txt : ^ 1.5.0 => 1.5.0
gatsby-plugin-sharp : ^ 2.2.18 => 2.2.18
gatsby-plugin-sitemap : ^ 2.2.9 => 2.2.9
개츠비 발언 이미지 : ^ 3.1.19 => 3.1.19
gatsby-remark-prismjs : ^ 3.3.9 => 3.3.9
개츠비 소스 파일 시스템 : ^ 2.1.18 => 2.1.18
개츠비 변압기 발언 : ^ 2.6.19 => 2.6.19
개츠비 변압기 날카로운 : ^ 2.2.12 => 2.2.12
npmGlobalPackages :
gatsby-cli : 2.7.40

동일한 문제가 발생했습니다. 사이트가 Netlify에 완벽하게 구축되었지만 gatsby build 및 gatsby develop 둘 다 사용하여 개발 시스템에 중단되었습니다.

패키지 버전을 가지고 놀다가 버전 2.2.10에서 2.2.9로 gatsby-plugin-sitemap 를 되 돌리면 문제가 해결된다는 것을 알았습니다. 이상하게도 여기에있는 일부 사람들은 2.2.9에 문제가있는 것 같습니다. 이는 문제가 다른 곳에 있음을 의미 할 수 있습니다.

편집 : 너무 빨리 말하면 Gatsby는 훨씬 덜 자주 "소스 및 변환 노드"및 "createPagesStatefully"단계에서 멈 춥니 다.

@goblindegook 이것은이 특정 문제에서 일반적인 패턴으로 보입니다. 겉보기에 날씨, 시간, 부팅 후 시간과 관련하여 문제가 발생하고 사라지기 때문에 수행 한 작업이 문제를 해결했다고 믿을 수 있습니다.

이 문제도 경험하면서 gatsby-plugin-sitemap 을 2.2.6으로 다운 그레이드했으며 그 결과 해결 된 것 같습니다.

FWIW, 나는 또한 이것을 경험하고 있지만 yarn 또는 gatsby-plugin-sitemap 사용하지 않습니다.

내 gatsby info 도움이되는 경우 :

  System:
    OS: macOS 10.14.6
    CPU: (4) x64 Intel(R) Core(TM) i7-7567U CPU @ 3.50GHz
    Shell: 5.3 - /bin/zsh
  Binaries:
    Node: 12.9.1 - /usr/local/bin/node
    npm: 6.11.2 - /usr/local/bin/npm
  Languages:
    Python: 3.7.4 - /usr/local/opt/python/libexec/bin/python
  Browsers:
    Chrome: 76.0.3809.132
    Firefox: 68.0.1
    Safari: 12.1.2
  npmPackages:
    gatsby: ^2.15.1 => 2.15.1 
    gatsby-cli: ^2.7.41 => 2.7.41 
    gatsby-image: ^2.2.15 => 2.2.15 
    gatsby-plugin-catch-links: ^2.1.6 => 2.1.6 
    gatsby-plugin-google-tagmanager: ^2.1.7 => 2.1.7 
    gatsby-plugin-manifest: ^2.2.12 => 2.2.12 
    gatsby-plugin-offline: ^3.0.0 => 3.0.0 
    gatsby-plugin-react-helmet: ^3.1.5 => 3.1.5 
    gatsby-plugin-sass: ^2.1.12 => 2.1.12 
    gatsby-plugin-sharp: ^2.2.18 => 2.2.18 
    gatsby-remark-images: ^3.1.19 => 3.1.19 
    gatsby-source-filesystem: ^2.1.18 => 2.1.18 
    gatsby-transformer-remark: ^2.6.19 => 2.6.19 
    gatsby-transformer-sharp: ^2.2.12 => 2.2.12 
    gatsby-transformer-yaml: ^2.2.7 => 2.2.7 
  npmGlobalPackages:
    gatsby-cli: 2.7.41

나를 위해 gatsby clean 캐시를 정리하면 문제가 해결되었습니다.

나는 이것을 알아 내려고 아직도 사냥을하고있다. 나에게는 여전히 문제입니다. 이것이 바벨 7.0.0-> 7.5.5의 전환과 관련이 있는지 아는 사람이 있습니까? 이 스위치는 내가이 버그를 경험하기 시작했을 때 발생했고 문제가 보이기 시작하는 것과 일치합니다 ... 나는 7.0.0에서 바벨 버전을 고정하기 위해 실 해상도를 작동 시키려고 노력했지만 성공하지 못했습니다. 아직.

약간의 통찰력을 제공 할 수 있다고 생각합니다. 프로젝트에 플러그인을 추가하는 도중에 다른 터미널 창에서 gatsby-cli를 업데이트했을 때이 문제가 발생하기 시작했습니다. 내 프로젝트에서 gatsby clean 을 (를) 실행했습니다.

https://github.com/gatsbyjs/gatsby/issues/6385#issuecomment -531949380에서-이 문제도보고 있지만 gatsby clean 해결되지 않았습니다. CLI 출력물이 멈춘 것처럼 보이는데, 터미널 크기를 조정하면 문제가 해결됩니까 ?? 🤷‍♂ 😕 ❓❗️

터미널 창 크기를 조정하면 문제가 해결되는 것 같습니다! 나는 그것을 매우 광범위하게 테스트하지 않았습니다.이 문제가있는 다른 사람들도 이것을 시도 할 수 있습니까? 얼마나 이상한 버그이고 잠재적으로 이상한 솔루션입니다.

저는 똑같은 문제에 직면하고 있습니다. gatsby는 "소스 및 변환 노드"또는 "createPagesStatefully"에 자주 갇혀 있고 저는 소스 플러그인을 사용하지 _ 않습니다 _. 나는 최근에야 "단말기 창 크기 조정"수정을 만났고 이것이 어떻게 수정되는지에 대해 140 % 당황 스러웠지만 그렇게한다. 이것은 매우 심각한 문제인 것 같습니다!

@JaKXz- 감사합니다! 이것은 나를 미치게 만들었다. 수정 사항은 VS Code에서 터미널 창 크기를 조정하는 것 같습니다. 약간 위나 아래로 드래그하면 개발 작업이 행복하게 진행됩니다. 나는 yarn과 npm, workspaces와 아닌 두 가지 다른 경우에서 테스트했습니다. 나를 위해 모든 경우에서 일하는 것 같았습니다. 또한 동결 또는에서 걸어 것으로 보인다 createPagesStatefully 보다 더 자주 source and transform nodes 지금 나를 위해. 지금은 문제를 열어 두겠습니다.이 문제는 저보다 더 많은 지식을 가진 사람이 덜 "해키"방식으로 해결해야 할 수도 있습니다.

@ehowey 나는 같은 문제가 있고 vscode에서 터미널 창을 이동하면 작동합니다 (내가 시도하기 전까지이 문제를 읽을 때 믿을 수 없었습니다).
VS Code에서만 발생하는지 아십니까?

iTerm 2 에서이 문제가 있으므로 VS 코드와 관련이 없습니다.

내 문제는 iTerm 2에도 있습니다.

Webstorm 터미널, Mac 터미널, iTerm

크기 조정 터미널 수정이 다른 개발 환경에서 모두를 위해 작동 했습니까?

결국 터미널 크기 조정은 iTerm 및 VSCode에서 작동했습니다 (iTerm에서 문제를 재현하기 위해 몇 번 시도했습니다)

크기 조정 터미널 트릭은 iTerm 2에서 안정적으로 작동합니다.

네, iTerm 2 크기 조정이 완벽하게 작동합니다.

크기 조정이 작동하면이 버그가 버퍼와 ​​관련된 것으로 의심되며 어딘가에 stdout 플러시가 필요합니다.

이런 종류의 커널 + 쉘 관련 문제처럼 보입니다. 아마도 노드가 커널 및 / 또는 셸과 상호 작용하는 방식 일 것입니다. 나는 Linux 또는 Windows를 사용하여 문제를 복제 할 수 없기 때문에 이것을 말합니다. 알려진 문제를 찾을 수없는 것 같습니다. 따라서 a) Gatsby 고유의 코드 패턴과 시스템과의 상호 작용의 조합이거나 b) 아직 물어볼 올바른 질문을 모릅니다.

터미널 크기를 조정하여 문제가 해결되면 노드와 kqueue 사이에 결함이 발생하여 이벤트 루프에서 블록이 발생할 수 있습니다. 터미널의 크기를 조정하면 프로세스에 SIGWINCH 신호가 전송되어 이벤트 루프가 중단되고이를 해제하고 계속할 수 있습니다.

실행중인 프로세스가 멈출 때 kill -SIGWINCH ${pid} 실행 해 볼 수 있습니까? 터미널 크기 조정과 동일하게 작동해야합니다.

나는 또한 이것이 모든 쉘에서 발생하는지 여부에 관심이 있습니다. 지금까지의 정보에 따르면 bash 및 zsh 에서 실패했으며 이는 아마도 모든 터미널 에뮬레이터 간의 공통 요인 중 하나 일 것입니다. sh , csh , ksh , tcsh 등 중 하나 이상을 시도해 볼 수 있습니까?

모든 셸에서 문제가 발생하면 커널이 노드의 이벤트 루프를 처리하는 방식이라고 생각합니다. 이것이 간헐적 인 문제인 이유이기도합니다. 일부 함수가 프로세서 시간을 줄이면 (가변 시스템로드로 인해) 너무 오래 차단 될 수 있으며 커널이 어딘가에서 이벤트 노드를 재사용하려고 시도하여 교착 상태가 발생할 수 있습니까? 나는 api의 내부에 익숙하지 않지만 source and transform nodes 은 상당히 파일 시스템 IO 집약적이라고 확신합니다. 이는 아마도 많은 오프 로딩이 일어나고 있다는 것을 의미하므로 누가 낮은 수준에서 실제로 무슨 일이 일어나고 있는지 알 수 있습니다.

이 버그의 표면적을 좁히는 것이 좋은 생각이라고 생각합니다. source and transform nodes 에서 가장 자주 발생합니다. 모양이되므로 플러그인이 차단하는 범위로 좁혀보세요. node_modules/gatsby/dist/utils/api-runner-node.js 다음 줄을 추가해보세요.

+ 347       if (api === `sourceNodes`) {
+ 348         debugger;
+ 349       }
  350       resolve(runAPI(plugin, api, Object.assign({}, args, {
  351         parentSpan: apiSpan
  352       })));

그런 다음 node inspect node_modules/.bin/gatsby develop 합니다. 당신이 명중 할 수 있도록 그것은 즉시 시작으로 중단됩니다 c 당신이에 도착하면 debug> 프롬프트를 대기가 계속합니다. debugger 줄에서 끊어지면 exec console.log(plugin) 쓰고 resolve 합니다. 그런 다음 계속하려면 c 를 누르십시오. 그냥이 정지하면 ... 할 때까지 컴퓨터가이 작업을 수행.

이벤트 루프의 특성 때문에 디버깅 중에도 멈추지 않을 것입니다. 이러한 인터럽트는 아마도 그것을 추적하기에 충분할 것입니다. 비동기 버그는 추적하기가 정말 힘들 수 있습니다. 디버거를 사용하는 동안 중단되지 않으면 debugger 줄을 다음으로 바꿉니다.

reporter.log(plugin.resolve);

바라건대 그것은 뭔가를 드러 낼 것입니다. 어떤 플러그인이 차단을 일으키는 지 보는 것이 좋을 것입니다. 우리가 그것을 알아낼 수 있다면, 이것을 분류하기 위해 최적화 / 리팩토링되어야하는 것이 무엇인지 알아낼 수있을 것입니다.

크기 조정도 나에게도 효과가 있으며 zsh를 VSCode 셸로 사용합니다.

@ Js-Brecht-자세한 답변에 시간을 내 주셔서 감사합니다. kill -SIGWINCH ${pid} 정확히 어디에 입력해야하는지 잘 모르겠습니다. 빌드 과정에서 할 수 없었습니다.

디버거를 사용하면 다음 코드가 나왔습니다. 나는 실제로 디버거에 갇혀 있었지만 .exit 여전히 작동했습니다.

⠋ source and transform nodes
break in /Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/utils/api-runner-node.js:365
 363       return new Promise(resolve => {
 364         if (api === `sourceNodes`) {
>365           debugger;
 366         }
 367         resolve(

< {
<   resolve: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/internal-plugins/internal-data-bridge',
<   id: 'a5079d69-ba80-53dc-82f9-0f440bd5448c',
<   name: 'internal-data-bridge',
<   version: '1.0.0',
<   pluginOptions: { plugins: [] },
<   nodeAPIs: [ 'sourceNodes', 'onCreatePage' ],
<   browserAPIs: [],
<   ssrAPIs: []
< }
< ⠋ source and transform nodes
debug> undefined
debug> c
break in /Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/utils/api-runner-node.js:365
 363       return new Promise(resolve => {
 364         if (api === `sourceNodes`) {
>365           debugger;
 366         }
 367         resolve(
⠦ source and transform nodes
break in /Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/utils/api-runner-node.js:365
 363       return new Promise(resolve => {
 364         if (api === `sourceNodes`) {
>365           debugger;
 366         }
 367         resolve(
{
<   resolve: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-plugin-mdx',
<   id: '479d2e25-5a33-5a59-a290-cf1877d39ee5',
<   name: 'gatsby-plugin-mdx',
<   version: '1.0.43',
<   pluginOptions: {
<     plugins: [ [Object] ],
<     extensions: [ '.md', '.mdx' ],
<     defaultLayouts: {
<       default: '/Users/erichowey/Coding/gatsby-catalyst/themes/gatsby-theme-catalyst-core/src/components/layout.js'
<     },
<     gatsbyRemarkPlugins: [ [Object], [Object], [Object] ],
<     remarkPlugins: [ [Function: slug] ]
<   },
<   nodeAPIs: [
<     'sourceNodes',
<     'onCreateNode',
<     'onCreatePage',
<     'onCreateWebpackConfig',
<     'resolvableExtensions',
<     'preprocessSource',
<     'onCreateBabelConfig',
<     'onPreBootstrap',
<     'onPostBootstrap'
<   ],
<   browserAPIs: [ 'wrapRootElement' ],
<   ssrAPIs: [ 'wrapRootElement' ],
<   pluginFilepath: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-plugin-mdx'
< }
< ⠦ source and transform nodes
debug> undefined
{
<   resolve: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-plugin-mdx',
<   id: '479d2e25-5a33-5a59-a290-cf1877d39ee5',
<   name: 'gatsby-plugin-mdx',
<   version: '1.0.43',
<   pluginOptions: {
<     plugins: [ [Object] ],
<     extensions: [ '.md', '.mdx' ],
<     defaultLayouts: {
<       default: '/Users/erichowey/Coding/gatsby-catalyst/themes/gatsby-theme-catalyst-core/src/components/layout.js'
<     },
<     gatsbyRemarkPlugins: [ [Object], [Object], [Object] ],
<     remarkPlugins: [ [Function: slug] ]
<   },
<   nodeAPIs: [
<     'sourceNodes',
<     'onCreateNode',
<     'onCreatePage',
<     'onCreateWebpackConfig',
<     'resolvableExtensions',
<     'preprocessSource',
<     'onCreateBabelConfig',
<     'onPreBootstrap',
<     'onPostBootstrap'
<   ],
<   browserAPIs: [ 'wrapRootElement' ],
<   ssrAPIs: [ 'wrapRootElement' ],
<   pluginFilepath: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-plugin-mdx'
< }
< ⠦ source and transform nodes
debug> undefined
debug> c
break in /Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/utils/api-runner-node.js:365
 363       return new Promise(resolve => {
 364         if (api === `sourceNodes`) {
>365           debugger;
 366         }
 367         resolve(
{
<   resolve: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-transformer-sharp',
<   id: '822bdf7b-a95a-5885-9351-158705910ac3',
<   name: 'gatsby-transformer-sharp',
<   version: '2.2.16',
<   pluginOptions: { plugins: [] },
<   nodeAPIs: [
<     'onCreateNode',
<     'setFieldsOnGraphQLNodeType',
<     'onPreExtractQueries',
<     'sourceNodes'
<   ],
<   browserAPIs: [],
<   ssrAPIs: [],
<   pluginFilepath: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-transformer-sharp'
< }

⠋ source and transform nodes
break in /Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/utils/api-runner-node.js:365
 363       return new Promise(resolve => {
 364         if (api === `sourceNodes`) {
>365           debugger;
 366         }
 367         resolve(

< {
<   resolve: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/internal-plugins/internal-data-bridge',
<   id: 'a5079d69-ba80-53dc-82f9-0f440bd5448c',
<   name: 'internal-data-bridge',
<   version: '1.0.0',
<   pluginOptions: { plugins: [] },
<   nodeAPIs: [ 'sourceNodes', 'onCreatePage' ],
<   browserAPIs: [],
<   ssrAPIs: []
< }
< ⠋ source and transform nodes
debug> undefined
debug> c
break in /Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby/dist/utils/api-runner-node.js:365
 363       return new Promise(resolve => {
 364         if (api === `sourceNodes`) {
>365           debugger;
 366         }
 367         resolve(
{
<   resolve: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-source-filesystem',
<   id: '339022db-842c-55bd-8e87-d84bd74a175a',
<   name: 'gatsby-source-filesystem',
<   version: '2.1.26',
<   pluginOptions: { plugins: [], name: 'src', path: 'src/' },
<   nodeAPIs: [ 'sourceNodes', 'setFieldsOnGraphQLNodeType' ],
<   browserAPIs: [],
<   ssrAPIs: [],
<   pluginFilepath: '/Users/erichowey/Coding/gatsby-catalyst/node_modules/gatsby-source-filesystem'
< }
< ⠋ source and transform nodes
debug> undefined
⠹ source and transform nodes
debug> exec console.log(plugin)
c
c

터미널을 사용하는 macOS Sierra의 크기 조정이 저에게 효과적이었습니다.

@ehowey 내가 당신을 올바르게 이해하고 있다는 것을 알기 때문에 디버거에있는 동안 중단 되었습니까? 이 경우 gatsby-source-filesystem 가 범인 인 것처럼 보입니다. 특히 기존의 관련 개츠비 문제로 인해 말이됩니다.

플러그인이 테스트 실행을 처리 할 수 ​​있는지 확인하고 싶습니다. 테스트를 실행하는 동안 중단되면 실패한 부분을 쉽게 확인할 수있는 방법이라고 생각합니다. 그렇지 않다면 ... 제가 MacOS를 가지고 있지 않기 때문에 해부 / 디버깅을해야합니다. 저에게는 어려울 것입니다.

메인 개츠비 저장소를 다운로드하고 gatsby-source-filesystem 테스트를 실행할 수 있습니까?

> git clone [email protected]:gatsbyjs/gatsby.git gatsby-js
> cd gatsby-js
> yarn bootstrap
> yarn jest -- -i './packages/gatsby-source-filesystem/src'

또한 최소 복제 저장소로이 모든 작업을 수행하고 있습니까? gatsby-plugin-mdx 가 두 번 실행되었으므로 베어 본 저장소가 아님을 알 수 있습니다. 완벽한 세상에서는 중요하지 않지만 가능한 한 간단한 설정을 실행하는 것이 더 낫다고 생각합니다. 최소한의 리포지토리로 안정적으로 실패 할 수없는 경우 가장 일관되게 실패하는 항목을 사용하십시오 (동일한 장소에서 매번 (또는 가까이에))

😉

kill -SIGWINCH ${pid} 는 다른 셸 인스턴스에서 실행해야합니다. 빌드가 중단되면 다른 터미널 창 / 탭을 열고 거기에서 명령을 실행하십시오. 이 작은 스 니펫 이 작동합니다.

pid=$(ps -ef |grep -E 'node.*index\.js develop' |awk '{ print $2 }').
kill -SIGWINCH $pid

# Can also be run like this
kill -SIGWINCH $(ps -ef |grep -E 'node.*index\.js develop' |awk '{ print $2 }')

오류가 있으면 명령을 별도로 실행 해보십시오.

# Run first
ps -ef grep -E 'node.*index\.js develop'
# Example output
     UID     PID    PPID  TTY        STIME COMMAND
********   39928       1 cons0    06:47:38 /path/to/node /path/to/gatsby-cli/lib/index.js develop
# Second column is the pid you want
kill -SIGWINCH 39928

테스트를 실행 한 후 빈손으로 나오면 코어 덤프를 사용하는 것이 유용 할 것이므로 스택 추적을 얻을 수 있습니다. 그러나 한 번에 한 단계 씩.

@ Js-Brecht 응답이 느려서 죄송합니다 ... 이것은 정말 저녁에 여가 시간에하는 취미입니다.

그래서 나는 gatsby hello world 스타터 내부에서 똑같은 것을 실행했습니다. 문제가 있었던 프로젝트의 주 작업 공간에서 전에 실행했습니다. 나는 이전에 그것을 처음부터 복제 했으므로 플러그인과 관련이 없다고 생각하지만 개츠비의 핵심에있는 것입니다.

소스 및 변환 노드에 매달려 다음 출력을 제공합니다.

< success onPreBootstrap - 0.102 s
⠋ source and transform nodes
break in node_modules/gatsby/dist/utils/api-runner-node.js:362
 360       return new Promise(resolve => {
 361         if (api === `sourceNodes`) {
>362           debugger
 363         }
 364         resolve(

< {
<   resolve: '/Users/erichowey/Coding/my-hello-world-starter/node_modules/gatsby/dist/internal-plugins/internal-data-bridge',
<   id: 'a5079d69-ba80-53dc-82f9-0f440bd5448c',
<   name: 'internal-data-bridge',
<   version: '1.0.0',
<   pluginOptions: { plugins: [] },
<   nodeAPIs: [ 'sourceNodes', 'onCreatePage' ],
<   browserAPIs: [],
<   ssrAPIs: []
< }
< ⠋ source and transform nodes
debug> undefined

< success source and transform nodes - 25.137 s

다음은 도움이되는 경우에 대비 한 gatsby info 명령의 덤프입니다.

  System:
    OS: macOS High Sierra 10.13.6
    CPU: (2) x64 Intel(R) Core(TM)2 Duo CPU     P8600  @ 2.40GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 12.9.1 - /usr/local/bin/node
    Yarn: 1.17.3 - /usr/local/bin/yarn
    npm: 6.10.3 - /usr/local/bin/npm
  Languages:
    Python: 2.7.10 - /usr/bin/python
  Browsers:
    Chrome: 76.0.3809.132
    Firefox: 67.0.2
    Safari: 13.0.1
  npmPackages:
    gatsby: ^2.15.22 => 2.15.22 
  npmGlobalPackages:
    gatsby-cli: 2.7.47

참고로 디버그 명령을 사용하면 소스 및 변환 노드에서 중단됩니다. 내가 gatsby develop을 사용할 때 대부분은 나를 위해 createPagesStatefully에 매달려 있습니다. 정말 이상한 일이라는 것을 알고 미안합니다. 솔직히 말해서 당신의 일에서 얼마나 많은 일이 가치가 있는지 잘 모르겠습니다. 터미널 창 크기 조정 트릭은 나와 다른 사람들에게 매번 작동합니다. 해키 픽스이지만 많은 사용자에게 영향을 미치지 않아야합니다. 그렇지 않으면 문제가 범람 할 것입니다.

이것은 여기에서도 일어나기 시작했습니다. _resize the terminal_ 트릭은 그것을 해결합니다. 매우 이상합니다!

+1 iTerm2에서는 작동하지 않지만 터미널에서는 작동합니다 🤷‍♂️

@ehowey 빌드 중에 발생하는 대부분의 작업은 하나 또는 다른 플러그인에 의해 정의됩니다. Gatsby는 종속성으로 제공됩니다. 핵심 플러그인으로 간주 될 수 있다고 생각합니다. Gatsby 코어는 플러그인에 정의 된 엔드 포인트를 찾고 코어에 정의 된 작업 / 객체를 포함하는 일련의 인수를 전달하는 API를 노출합니다. 네, 무슨 일이 일어나고 있는지 핵심에서 일어날 수 있지만, 먼저 플러그인을 호출해야하고, 이러한 플러그인은 API에 대한 특정 컨텍스트를 정의합니다. 빌드 중단을 초래하는 컨텍스트를 확인하고 플러그인 자체에서 문제가 발생하지 않는지도 확인해야합니다.

이 라인을 변경하도록 할 수 있습니까?

 360       return new Promise(resolve => {
-361         if (api === `sourceNodes`) {
-362           debugger
-363         }
+364         reporter.log(`${api}\t${plugin.name}`)
 365         resolve(

이것을 실행하고 전체 출력을 복사 / 붙여 넣기하십시오 (응답에 .txt 파일로 첨부 할 수도 있음). 훨씬 더 장황 할 것이고 많은 정보가 아마도 불필요 할 것입니다. 그러나 🤷‍♂.

그렇게 한 후에 노드의 스레드 풀을 늘리면 차이가 있는지보고 싶습니다. 동일하거나 유사한 문제를 언급하는 다른 문제를 발견했습니다. 대부분 source and transform 에서 발생하며 일부는 그 단계가 영원히 걸리거나 완전히 잠기는 것에 대해 이야기합니다. 따라서 파일 시스템 io에서 일종의 교착 상태가 발생하는지 확인하고 싶습니다. 비동기 파일 시스템 액세스는 노드에서 다른 스레드로 오프로드되며 기본적으로 노드에는 사용자 공간에 대한 4 개의 스레드 풀만 있습니다. 이것이 채워지고 더 이상 오프 로딩을 수행해야하는 경우 작업은 기본 이벤트 루프에서 대기열에 추가되어 스레드를 기다립니다. 이것은 스레드가 사용 가능해질 때까지 잠재적으로 전체 프로그램을 정지시킬 수 있습니다. Gatsby는 파일 시스템에 캐시를 유지하므로 어딘가에서 충돌이 발생하고 어떤 종류의 교착 상태가 발생하면 스레드가 계속 진행하기 전에 시간 초과 / 인터럽트를 기다리고있을 수 있으며 수십 개 (또는 수백 개) 파일 시스템 액세스 이벤트의 경우 모두 동일한 시간 초과를 기다리며 모든 것이 쌓일 수 있습니다. 이로 인해 대기 시간이 다소 빠르게 증가 할 수 있음을 알 수 있습니다.

풀 크기를 늘리면 트래픽의 일부를 줄이는 데 도움이 될 수 있습니다. 또는 더 많은 스레드를 사용하여 같은 방식으로 발생할 수 있습니다 😆.
다음 명령을 시도하십시오.

UV_THREADPOOL_SIZE=10 gatsby develop

@ Js-Brecht 스레드 풀 크기를 변경해도 큰 차이가없는 것 같습니다.
위에서 언급 한 변경 사항으로 표준 gatsby develop 명령에서 다음 출력을 얻습니다. 여전히 기본적인 hello-world 개츠비 스타터에 있습니다.

Erics-MBP:my-hello-world-starter erichowey$ gatsby develop
success open and validate gatsby-configs - 0.050 s
success load plugins - 0.119 s
success onPreInit - 0.036 s
success initialize cache - 0.050 s
success copy gatsby files - 0.281 s
onPreBootstrap  load-babel-config
success onPreBootstrap - 0.131 s
sourceNodes     internal-data-bridge
success source and transform nodes - 0.105 s
success Add explicit types - 0.030 s
success Add inferred types - 0.186 s
success Processing types - 0.145 s
success building schema - 0.535 s
success createPages - 0.032 s
createPagesStatefully   dev-404-page
onCreatePage    internal-data-bridge
onCreatePage    prod-404
createPagesStatefully   gatsby-plugin-page-creator
createPagesStatefully   gatsby-plugin-page-creator
createPagesStatefully   gatsby-plugin-page-creator
createPagesStatefully   gatsby-plugin-page-creator
createPagesStatefully   gatsby-plugin-page-creator
createPagesStatefully   gatsby-plugin-page-creator
onCreatePage    internal-data-bridge
onCreatePage    prod-404
success createPagesStatefully - 9.098 s
success onPreExtractQueries - 0.030 s
success update schema - 0.129 s
success extract queries from components - 0.336 s
success write out requires - 0.057 s
success write out redirect data - 0.044 s
success onPostBootstrap - 0.045 s
⠀
info bootstrap finished - 16.437 s
⠀
success run static queries - 0.038 s
success run page queries - 0.109 s — 2/2 27.65 queries/second
onCreateWebpackConfig   webpack-theme-component-shadowing
onCreateWebpackConfig   webpack-theme-component-shadowing
success start webpack server - 1.506 s — 1/1 4.63 pages/second
 DONE  Compiled successfully in 4699ms

이것은 createPagesStatefully 에 매달린 예입니다. 터미널 창 크기를 조정하여 빌드를 계속했습니다. 어떤 식 으로든 범인이 될 수있는 기회가 internal-data-bridge 입니까? 그것은 당신이 지금까지 실행하도록 요청한 두 명령에 모두 포함되었습니다.

어떤 줄에 매달려 있는지 보여줄 수 있습니까?

createPagesStatefully dev-404-page

dev-404-page 부분이 아직 있는지 100 % 확실하지 않지만 createPagesStatefully 의 첫 번째 인스턴스에 걸려 있습니다.

감사. 괜찮으 시다면 지금 좀 더 변경 해보고 싶습니다.

다음 파일에서 표시된 줄을 업데이트하십시오.

node_modules/gatsby/dist/internal-plugins/internal-data-bridge/gatsby-node.js

- 114   chokidar.watch(pathToGatsbyConfig).on(`change`, () => {
+ 114   chokidar.watch(pathToGatsbyConfig, { useFsEvents: false }).on(`change`, () => {

node_modules/gatsby/dist/internal-plugins/dev-404-page/gatsby-node.js

- 30     chokidar.watch(source).on(`change`, () => copy()).on(`ready`, () => done());
+ 30     chokidar.watch(source, { useFsEvents: false }).on(`change`, () => copy()).on(`ready`, () => done());

node_modules/gatsby-page-utils/dist/watch-directory.js

  26               chokidar.watch(glob, {
  27                 cwd: path,
+ 28                 useFsEvents: false,
  29               }).on("add", function (path) {

node_modules/gatsby/dist/utils/get-static-dir.js

- 51   chokidar.watch(staticDir).on(`add`, path => {
+ 51   chokidar.watch(staticDir, { useFsEvents: false }).on(`add`, path => {

node_modules/gatsby/dist/query/query-watcher.js

- 237   watcher = chokidar.watch([slash(path.join(rootDir, `/src/**/*.{js,jsx,ts,tsx}`)), ...packagePaths]).on(`change`, path => {
+ 237   watcher = chokidar.watch([slash(path.join(rootDir, `/src/**/*.{js,jsx,ts,tsx}`)), ...packagePaths], { useFsEvents: false }).on(`change`, path => {

나는 여기에서 chokidar 잘못이 의심됩니다. 약 한 달 전에 v3.x로 업그레이드되었으며 fsevents 사용하기 시작했거나 fsevents 와 관련하여 잘못된 동작을 유발하는 작업을 수행 한 것 같습니다. 여기에는 chokidar.watch() 사용할 때 노드가 중단되는 문제와 유사한 몇 가지 공개 된 문제가 있습니다. fsevents 가 Mac 프로세스이기 때문에 MacOS로 지역화되고 빌드가 사용중인 모듈 또는 파일을 작성 / 처리하는 모듈에서 실패하는 것처럼 보이기 때문에 적합 해 보입니다. 보고있을 가능성이 높습니다.

chokidar.watch() gatsby-source-filesystem chokidar.watch() 존재하며 다른 저장소 @ehowey에서 실패했습니다. 말할 것도없이, gatsby-source-filesystem 은 (는) 최소 저장소에서 호출되지 않으므로 source and transform 지나가는 이유를 설명합니다. 이의 인스턴스 chokidar 전에 internal-data-bridge ,하지만 난 빌드에 영향을 미치는되지 않는 위치에 생각한다 (예 : query-watcher ). 그러나 internal-data-bridge 가 디버거를 실행하는 동안 중단 된 이유라고 생각합니다. 곧바로 실행하면 빌드의 후반 단계에 영향을 미칠 가능성이 큽니다.

이로 인해 문제가 해결되는지 또는 이전보다 더 많이 발생하더라도 알려주십시오. : crossed_fingers :

@ Js-Brecht 당신은 어딘가에 얻고 있습니다! 나는 gatsby develop 아마 15 번 달렸다. 그것은에 걸려 결코 source and transform nodes 또는 createPagesStatefully 그러나에, 어쩌면, 2/10 시간을 걸 듯 start webpack server . 크기 조정 터미널 트릭과 함께이 문제를 해결할 수 있습니다. start webpack server 와 관련된 chokidar / fsevents의 인스턴스를 놓친 적이 있습니까?

부수적으로 개발 프로세스 단계를 이전보다 훨씬 빠르게 진행하는 것처럼 보였습니까?

정말 듣기 좋습니다. 일부러 chokidar 인스턴스 하나를 남겨두고 부트 스트랩을 완료하고 서버를 시작한 직후입니다. startServer() 함수의 끝 부분에서 node_modules/gatsby/dist/commands/develop.js startServer() 있습니다. 나는 지금 컴퓨터에 있지 않다. 아니면 당신에게 차이를 줄 것이다.

다음을 수행하여 정확한 줄을 찾을 수 있습니다.

cat node_modules/gatsby/dist/commands/develop.js |grep -n ‘chokidar’

이것이 부트 스트랩을 고친다면 여전히 서버에 매달려 있어야 할 것이라고 확신했습니다. 변경 사항이 안정적으로 실행되는지 알려 주시면 PR을 제출하고 사람들에게 알리겠습니다.

나는 그것이 더 빨리 실행된다는 사실에 놀랍지 않습니다. 베어의 빌드는 일반적으로 프로젝트 어쩌면 둘째 날 소요, 나는 당신의 디버그 출력의 특정 단계에 대한 어떤 미친 긴 런타임을 보았다. fsevents 는 속도를 높이고 CPU에서 많은 부하를 덜어 주지만, 대신 뭔가 재미있는 일이 일어나고 있습니다.

@ Js-Brecht 내 모자가 당신에게 간다. 나는 당신이 어떻게 그 토끼를 모자에서 뽑았는지 모르고 버그는 멀리서 그런 이상한 것을 고쳤지만 잘했습니다! 나는 잘못된 것을 변경하고 싶지 않기 때문에 diff가 develop.js 를 변경할 때까지 기다릴 것입니다. 시간.

차이점은 다음과 같습니다.

node_modules/gatsby/dist/commands/develop.js

- 337   chokidar.watch(watchGlobs).on(`change`, async () => {
+ 337   chokidar.watch(watchGlobs, { useFsEvents: false }).on(`change`, async () => {

이 모든 테스트를 실행 해 주셔서 정말 감사합니다. 이것은 까다로운 일 이었지만 MacOS의 내부를 파헤칠 수있는 기회였습니다. 저는 항상 새로운 것을 배우는 것을 즐깁니다. : slightly_smiling_face :

어떻게 진행되는지 알려주세요. 아직 숲에서 완전히 벗어나지 않았습니다. : sweat_ smile :.

공장! 방금 gatsby develop 10 번 이상 실행했는데 완벽하게 작동했습니다. 이 문제를 조사하는 데 도움을 주셔서 감사합니다. 바라건대 이것은 이것을 경험하는 우리 그룹에게 개선이되기를 바랍니다!

큰! 잠시 후에 여기에 몇 분이 있으면 PR을 작성하겠습니다. 완료되면 내 repo에서 gatsby-dev-cli 을 (를) 사용할 수 있으므로 패치가 게시 될 때까지 작업 개발 환경을 갖게됩니다 ( gatsby-dev-cli 익숙하지 않은 경우 도움). 나는 올바른 OS가 없기 때문에 어쨌든 변경 사항을 테스트하기 위해 당신을 모집 할 수 있습니다 ...이 문제를 겪고있는이 스레드의 다른 모든 사람들에게도 마찬가지입니다.

완료되면 여기에 다시 게시하겠습니다.

이 증상을 일으키는 또 다른 별도의 문제를 발견했습니다-https: //github.com/gatsbyjs/gatsby/issues/17935

누구든지 LokiJS를 사용하고 있고 터미널 크기를 조정해도 문제가 해결되지 않으면 내가 찾은 문제 일 가능성이 높습니다.

@ehowey 님 , PR # 17938을 확인하세요. 누군가가 기꺼이 테스트를한다면, PR에 줄을 서십시오.

내 저장소를 잡아서 gatsby-dev-cli 를 사용하여 사이트에서 gatsby 소스로 사용할 수 있습니다. 먼저 gatsby-dev-cli

# Use your package manager of choice, and install globally
npm install -g gatsby-dev-cli

그런 다음 저장소를 복제하고 부트 스트랩하십시오.

git clone --single-branch -b macos-fsevents-fix https://github.com/Js-Brecht/gatsby
cd gatsby
yarn bootstrap
# Set the target repo path for gatsby-dev
gatsby-dev -p "${PWD}"

그런 다음 리포지토리를 사용하려는 사이트로 이동하여 gatsby-dev

# Disable file watching, unless you intend on making changes to the gatsby repo
gatsby-dev --scan-once

제 경우에는 OSX와 IntelliJ를 사용하고 있습니다.

• IntelliJ에서 프로젝트 닫기
• 다시 시도 ( npm start )
• Intellij에서 프로젝트를 다시 엽니 다.
  문제가 IntelliJ 인덱싱 파일과 관련이 있다고 생각합니다.

@steinitz , @rheinardkorf , @ hbthen3rd , @sharvit , @JaKXz , @emilyaviva , @MaximeHeckel

# 17938을 테스트 해보실 분 계신가요?

오늘 밤 집에있을 때 살펴볼 수 있어야합니다. 이것에 대한 모든 작업에 감사드립니다!
2019 년 10 월 1 일 오전 10:23 -0600, Jeremy Albright [email protected] 은 다음과 같이 썼습니다.

@steinitz , @rheinardkorf , @ hbthen3rd , @sharvit , @JaKXz , @emilyaviva , @MaximeHeckel
# 17938을 테스트 해보실 분 계신가요?
—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 대화 목록을 음소거하세요.

이에 대한 수정 사항이 있습니까? [Firebase Source] Fetching data for ... 시도 후 소스에서 동결되고 나와 내 친구를 위해 노드를 변환합니다.

불행히도 터미널 크기를 조정해도 문제가 해결되지 않는 것 같습니다.

@ rishabhaggarwal2 현재 경험하고있는 것처럼 들리는 유사한 문제가 있는데, 온라인 소스에서 데이터를 검색하는 동안 중단됩니다. GATSBY_CONCURRENT_DOWNLOAD=10 gatsby develop 를 사용해 볼 수 있습니까?

이것도 본다. Lumen 시작시 로컬에서 gatsby develop 전혀 실행할 수 없습니다. createPageStatefully 또는 source and transform nodes 에 계속 걸려 있습니다.

macOS Mojave 10.14.6
Gatsby CLI version 2.7.7
Gatsby version 2.14.1

이 문제를 발견 한 다른 사람은

CHOKIDAR_USEPOLLING=1 gatsby develop

MacOS에서 fsevents 를 비활성화해야하므로 안정적인 해결 방법 인 것 같습니다.

@ Js-Brecht 여기에 언급 된 다른 해결 방법보다 더 영구적으로 수정하는 것 같습니다. 공유해 주셔서 감사합니다.

@steinitz 당신은 "더"를 영구적으로 말합니다. 그 스위치를 사용할 때 여전히 발생한다고 말하는 건가요?

@ Js-Brecht 아니요, 불분명해서 죄송합니다.

나는 내 자신을 포함한 다른 해결 방법이 한동안 작동하는 것처럼 보였지만 문제가 다시 발생했다는 사실을 암시했습니다. 귀하의 솔루션을 사용하여 변경 사항을 적용하고 gatsby develop을 다시 실행하여 (귀하의 개선 사항과 함께) 빌드를 계속해서 작동합니다.

즉, 이것은 롤러 코스터 타는 것이기 때문에 나는 감정적으로 준비되어 있습니다 : smile : 문제가 돌아올 수 있도록.

명확하게 말하면, 지금까지는 너무 좋습니다.

죄송합니다. 업데이트 :이 글을 게시하기 전에 최종 테스트를 위해 WebStorm을 다시 시작했으며 이제 WebStorm 터미널의 source and transform nodes 에 걸려 있습니다.

이 문제를 발견 한 다른 사람은

CHOKIDAR_USEPOLLING=1 gatsby develop

MacOS에서 fsevents 를 비활성화해야하므로 안정적인 해결 방법 인 것 같습니다.

@ Js-Brecht 나는 ubutu 18.04를 사용하고 있으며 가끔 같은 문제가 발생합니다. 내 OS에 대한 제안이 있습니까? 이 문제의 가능한 원인에 대해 자세히 설명 하시겠습니까?

이것은 @ Js-Brecht와 @RomanHotsiy의 부지런한 작업 덕분에 해결되었습니다. fsevents의 업스트림 문제 였는데, 제가 스스로 알아낼 수 있었던 것 이상으로, 이러한 변경 사항이 구현되고 fsevents에서 gatsby 자체로 마이그레이션되면 향후 업데이트에서 수정되어야합니다. 현재 신뢰할 수있는 해결 방법은 터미널 창 크기를 조정하는 것입니다. 여기에 설명 된 리포지토리 자체에서이 문제를 해결하는 방법이 있습니다. https://github.com/gatsbyjs/gatsby/pull/17938 그러나 다시 실행해야합니다. node_modules 폴더를 변경 한 후 수정하고 패키지 버전을 업데이트하는 빈도에 따라 작업 할 가치가 없을 수 있습니다.

수정 사항이 다운 스트림으로 개츠비 자체로 마이그레이션 될 때까지 문제를 열어 두겠습니다.

@ Boty22 Ubuntu는 fsevents 사용하지 않으므로 아마도 다른 것일 수 있습니다. 원격 위치에서 데이터를 검색 할 때 몇 가지 문제가 발생했습니다. 동시성 문제 수정에 대한 자세한 내용은 # 6654 및 # 17940을 확인하세요.

빠른 질문 : 터미널 크기 조정이 도움이됩니까? 그렇다면이 문제와 유사한 _ 무언가 _ 일 수 있습니다.

@ Js-Brecht의 터미널 크기 조정은 Ubuntu에 도움이되지 않습니다. 플러그인 gatsby-source-airtable BTW를 사용하여 AirTable 테이블에서 데이터를 검색하고 있습니다.

그게 문제가 될 수 있습니다. 이 의견을 확인하십시오. 그래도 작동하지 않으면 새 티켓을 여는 것이 좋습니다.

@steinitz 죄송합니다. 귀하의 의견을 놓쳤습니다. # 17938에 설명 된 수정을 시도 할 수 있습니까? 보다 구체적으로 여기 와 여기 . 작동하지 않으면 귀하의 경우에 더 많은 일이 발생했을 것입니다.

언급 된 이후 CHOKIDAR_USEPOLLING=1 gatsby develop 문제가 없었습니다.

@ Js-Brecht 해결 방법에 감사드립니다.

나는 개츠비 빌드를 할 때 2.15.28에서도 이것을보고 있습니다. 다른 터미널에서 개츠비 개발을 중지해야합니까? 간헐적으로 발생합니다.

개발 서버가 실행되지 않고 다시 발생했습니다. 그래도 블로그 튜토리얼을 따라 간단한 블로그가 있습니다.

거의 모든 다른 실행 인 것 같습니다. 나는 Mac btw를 사용하고 있습니다.

@canvaspixels 는 터미널 창 크기를 조정하면 빌드가 https://github.com/gatsbyjs/gatsby/pull/17938#issuecomment -540661991

@RomanHotsiy 정말 그것을 정렬합니다! 감사!

안녕하세요, fsevents 의 패치 버전이 게시되었습니다. yarn.lock 파일을 삭제하고 yarn을 다시 실행할 수 있어야합니다. 각 종속성은 자동으로 [email protected] 을 선택해야 문제가 해결됩니다.

주의하십시오. yarn.lock 파일 전체를 삭제하면 다른 패키지도 업그레이드 될 수 있습니다.

당신이 사용하는 경우 또 다른, 더 정확한 옵션 yarn 에 관한 단지 라인을 삭제하는 것입니다 fsevents 에서 yarn.lock 하고 다시 실행 yarn . 이로 인해 영향을받는 패키지 만 업그레이드됩니다. 예를 들어 다음 줄을 제거했습니다.

- 
- fsevents@^2.0.6:
-   version "2.0.7"
-   resolved "https://registry.yarnpkg.com/fsevents/-/fsevents-2.0.7.tgz#382c9b443c6cbac4c57187cdda23aa3bf1ccfc2a"
-   integrity sha512-a7YT0SV3RB+DjYcppwVDLtn13UQnmg0SWZS7ezZD0UjnLwXmy8Zm21GMVGLaFGimIqcvyMQaOJBrop8MyOp1kQ==

이를 수행하는 또 다른 방법은 Yarn (https://yarnpkg.com/lang/en/docs/selective-version-resolutions/)의 resolutions 기능을 사용하는 것입니다. 당신에 다음을 추가하면 package.json 다음 실행 yarn , 또한 전이 종속성을 업그레이드하고 업데이트합니다 yarn.lock 파일을 :

  "resolutions": {
    "fsevents": "^2.1.1"
  }

이 작업을 수행하고 잠금 파일을 업데이트 한 후 package.json 에서 resolutions 속성을 다시 제거 할 수 있습니다.

편집 : 이전의 잘못된 버전의 지침을 제거했습니다.

yarn upgrade chokidar@latest 실행할 수도 있습니다. 다른 어떤 것도 건드리지 않고 올바른 버전의 fsevents로 잠금 파일을 다시 빌드해야합니다.

아, 기다려. 그것은 당신이 직접 의존성으로 chokidar를 가지고있는 경우에만 가능합니다 🙄. 잊어 버렸습니다. @karlhorky 맞아요

npm 있습니다. 삭제 node_modules 실행 npm i --save [email protected] 다음과 npm i 나를 위해 트릭을했다. 시작하는 데 19 초가 걸렸고 gatsby-lumen-starter 를 기본으로 사용하고 있습니다.

-- 편집하다:

실제로 작업을 완료하고 Netlify로 푸시했는데 fsevents ( error [email protected]: The platform 'linux' is incompatible with this module ) 때문에 완전히 빌드 할 수 없었습니다.

나는 yarn 로 전환했고 같은 문제가있어서 fsevents 완전히 제거했고 이제 local과 netlify가 모두 작동합니다 ...

동일한 문제가 발생하여 이유를 추적 할 수 없습니다. 이것은 Mac과 PC 모두에서 발생합니다. 이것을 인터넷 속도와 관련시킬 수는 있지만 고속 네트워크에 연결되었을 때도 이런 일이 발생했습니다. 지금 나를 위해 일하는 것처럼 보이는 것은 내 환경에 이것을 추가하는 것입니다.

GATSBY_CONCURRENT_DOWNLOAD=5

--v8-pool-size=128 사용하여 실행

제 경우에는 osx에서 내 방화벽 프롬프트 인 것 같습니다. 외부에서 들어오는 연결을 허용하거나 거부 할만큼 빠르면 완벽하게 성공할 것입니다. 문제는 프롬프트 대화 상자가 잠시 동안 팝업되고 Gatsby가 계속됨에 따라 사라지고 위에서 언급 한 여러 단계 중 하나에서 중단되지 않는다는 것입니다.
옵션 :

• 방화벽 비활성화 (그것 없음)
• 화이트리스트 Gatsby (프로젝트 및 업그레이드간에 일관성이 없음)
• 사용자가 옵션을 선택할 때까지 프롬프트에서 중지하는 방법을 찾습니다.
• localhost에 대한 기본 바인드 주소 (수신 연결을 수락하기 위해 프롬프트가 필요하지 않아야 함).

@thomasthep dev 서버의 기본 바인드 주소는 이미 localhost입니다. 외부 IP 주소 (또는 0.0.0.0)를 사용하도록 지시하지 않는 한 외부 연결도 수신하지 않습니다. 그런 다음에도 부트 스트랩 / 빌드가 완료 될 때까지 개발 서버를 시작하지 않습니다. 방화벽 프롬프트를 유발하는 것이 부트 스트랩이라면 Gatsby가 기본 상태에서 인터넷에 연결하지 않기 때문에 사용중인 플러그인과 더 관련이 있습니다.

일반적으로 말해서 "외부에서 오는"연결도 없어야합니다. 플러그인이 외부 소스에서 정보를 수집하는 경우에도 연결은 외부 소스가 아닌 로컬 호스트에서 시작되며 대부분의 방화벽이 구성되어 있기 때문에 내 경험상 대부분의 방화벽에서 "설정된 연결"로 일반적으로 허용됩니다. 나가는 연결을 수락합니다.

방화벽이 연결이 아닌 프로세스를 차단하도록 구성된 경우 이런 일이 발생할 수 있습니다. 이 경우 화이트리스트에 추가해야하는 노드는 노드입니다.

왜 그런 일이 일어나는지 이해하려면 더 많은 정보가 필요합니다. 하지만 새 티켓을 여는 것이 더 효과적 일 것입니다. 이것은 MacOS에서 문제를 일으키는 fsevents 와 관련이 있었으며, 그 문제가 해결 되었기 때문에 지금 종료되었습니다. fsevents 와 (과) 관련이없는 것은 그 자체로 문제가 있어야합니다.

기록의 경우 GraphQL 서버가 디버그 모드에서 실행되고 중단 점에서 중지 된 경우에도 발생할 수 있습니다.

기록을 위해 : gatsby-source-s3-image 를 추가하고 s3 버킷이 100 개가 넘는 이미지에 도달했을 때 이런 일이 발생하기 시작했습니다. source and transform nodes 단계에서 145 개의 이미지를 모두 살펴본 다음 영원히 정지됩니다. 여전히 발생하고 있으며 위의 수정을 시도했습니다. 다행히도 5-6 시도 후에 작동하므로 차단되지 않습니다.

이상하게 터미널 창 크기를 조정하는 것이 효과적이었습니다.

나에게는 여기에 설명 된대로 동시 다운로드를 제한하는 것이 도움이되는 것 같습니다.

.env 파일에 다음 줄을 추가했습니다. 기본값은 200입니다.
GATSBY_CONCURRENT_DOWNLOAD=50

문제가 해결되는지 확실하지 않지만 누군가에게 도움이 될 수 있습니다. :)

@ rishabhaggarwal2 현재 경험하고있는 것처럼 들리는 유사한 문제가 있는데, 온라인 소스에서 데이터를 검색하는 동안 중단됩니다. GATSBY_CONCURRENT_DOWNLOAD=10 gatsby develop 를 사용해 볼 수 있습니까?

감사합니다.이 문제가 해결되었습니다. 제 3 자 웹 사이트에서 수많은 콘텐츠를 가져 왔기 때문에 콘텐츠 다운로드에 계속 매달 렸습니다. (97 %-너무 가깝지만 지금까지)