Gatsby: [bug fsevents] Terjebak di "source and transform node" / "createPagesStatefully" di MacOS

Diperbarui - Saya menguji mengomentari file gatsby-node.js dan membangun berkembang pada satu kesempatan, tetapi kemudian saya mencoba lagi dan melakukan ini dan macet di tempat yang sama lagi.

Apakah ada kemungkinan ini karena komputer kuno saya, Macbook Pro 2010 (ditingkatkan ke Ram 8GB dan SSD), belum menghentikan saya tetapi saya tahu hari-harinya terbatas. Ini adalah hobi bagi saya dan saya memiliki anak-anak yang masih kecil, jadi belum ada uang yang dikeluarkan untuk membeli komputer baru karena komputer ini bekerja dengan baik dengan Ram dan SSD yang ditingkatkan.

Saya telah mencoba kembali ke gatsby 2.13.52 yang merupakan versi terakhir saya stabil, saya juga mencoba kembali untuk bereaksi 16.8.6.

Menariknya saya berhasil membangunnya satu kali ketika saya kembali bereaksi ke 16.8.6 tetapi setelah itu pertama kali menutup telepon di tempat yang sama yang merupakan perilaku aneh bagi saya.

Saya juga bisa, jarang, tanpa alasan yang saya mengerti membuatnya baik-baik saja. Sepertinya tidak ada rima atau alasan saat ini terjadi. Saya menghabiskan beberapa jam mencari pola atau kesalahan yang mungkin menyebabkan ini tetapi tidak menemukan apa pun. Saya meninjau https://github.com/gatsbyjs/gatsby/issues/6654 dan mencoba beberapa item di sana tetapi tidak berhasil.

Bagi saya ini adalah salah satu bug paling aneh yang pernah saya temui karena perilakunya tampaknya berubah tanpa ada perubahan yang dapat dilihat dalam kode. Dalam beberapa kasus, build hang pada node sumber dan mengubah node (60% dari waktu), dalam beberapa kasus build hang di Create Pages Statefully (20%), dalam beberapa kasus build berhasil (20%). Saya telah memintanya untuk menampilkan ketiga perilaku ini tanpa mengubah satu baris kode pun.

Saya juga telah meniru perilaku ini di gatsby-starter-blog, yang sangat aneh. Sekali lagi itu membuat saya berpikir ini adalah masalah di pihak saya secara lokal. Menariknya itu hanya tergantung pada createPagesStatefully .

Saya sekarang mulai berpikir bahwa ini ada hubungannya dengan perpustakaan yang diperbarui oleh homebrew secara otomatis - yang mana saya tidak tahu tetapi itu adalah satu-satunya hal yang dapat saya pikirkan yang belum saya uji.

Berikut adalah daftar hal-hal yang telah saya coba sejauh ini:

• Mengubah versi node, mencoba 12, 10 dan 8

• Kembali ke poin sebelumnya dalam riwayat komit saya yang berfungsi - masih gagal sekarang.

• Mengomentari plugin dan area gatsby-config

• Mengomentari konten gatsby-node.js saya

• Uji lagi di Netlify, masih berhasil dibuat, itulah yang membuat saya berpikir pasti ada hubungannya dengan komputer saya.

• Menghapus 4 halaman di direktori src / pages saya dan memasukkan file index.mdx yang sangat mendasar

• Menghapus semua node_module dan mengunci file, menginstal ulang

• Memulai ulang komputer

• Membuat ruang kerja benang baru dengan klon baru dari tema / starter dari Github.

• Menguji gatsby-starter-blog, perilaku serupa tetapi hang pada createPagesStatefully

Halo,

Saya tidak dapat berbuat banyak tetapi mengonfirmasi bahwa saya melihat masalah ini di sejumlah pemula gatsby. Dan, seperti yang Anda tunjukkan, terkadang hanya memutuskan untuk membangun atau berhenti membangun, bergantung pada "node source and transform" atau createPagesStatefully.

Cukup membuat frustrasi dan mengarah pada upaya yang paling keterlaluan untuk memperbaikinya.

Saya tidak menyaksikan masalah ini tetapi ini terdengar aneh dan saya sangat ingin mengetahui alasan perilaku ini di pihak Anda.

Persiapan
Anda harus mencoba menggunakan node debugger untuk mengetahui akar masalahnya. Tugas di package.json Anda akan terlihat seperti ini. Jika Anda menggunakan VSCode, Anda dapat mengaktifkan "Auto Attach" untuk menggunakan debugger internal bersama dengan tugas ini (pastikan Anda menggunakan terminal internal untuk tujuan ini)

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

Debugging tentu saja akan berfungsi dengan IDE apa pun, tetapi pastikan Anda memasang debugger dengan benar.

1. Varian: Reproduksi Minimal
Anda telah menyebutkan createPagesStatefully sebagai sumber masalah. Jika Anda yakin itulah sumber masalahnya, mungkin Anda bisa membuat proyek yang sangat kecil untuk mereproduksinya. Tinggalkan semua permulaan, cukup gunakan gatsby secara langsung dan gunakan createPagesStatefully hingga gatsby-node.js dengan beberapa contoh yang meniru hal-hal yang dilakukan para pemula Anda. Kemudian mulai gatsby dan debug melalui pemeriksaan node.

Dengan cara itu Anda dapat menemukan tempatnya.

2. Alternatif: Di dalam proyek / starter Anda
Anda tentu saja dapat mencoba men-debug masalah di dalam proyek Anda dengan teknik yang sama. Tetapi mungkin Anda memiliki banyak masalah yang menumpuk dan mengaburkan pandangan Anda tentang penyebab masalah. Jadi saya akan selalu mencoba untuk mendapatkan reproduksi minimal sebelum memulai debug.

Semoga berhasil.

Jadi ... Saya mengalami beberapa perilaku aneh dengan file kunci. Mungkin seseorang yang tahu lebih banyak bisa mengarahkan saya ke arah yang benar. Dalam proses mencoba untuk mendapatkan bangunan kerja minimal saya pada dasarnya dipreteli ke instalasi Gatsby "hello world" dan masih tidak berfungsi yang benar-benar aneh.

Yang lebih aneh lagi adalah bahwa gatsby-starter-hello-world yang sebenarnya berfungsi dan dibangun dengan baik di komputer saya. TAPI ... jika saya menghapus file kunci dan mendapatkan benang untuk membangun kembali file kunci baru maka pembangunan mulai gagal, tergantung pada sumber dan mengubah node. Saya bisa mendapatkan implementasi yang dipreteli dan minimal untuk dibangun jika saya menyalin file kunci dari "hello-world" dan menggunakan ini. Jadi teori saya saat ini adalah bahwa ada beberapa jenis masalah versi di file kunci saya yang menyebabkan masalah ini tetapi saya terjebak di sini.

Saya juga menghapus semua penginstalan homebrew saya dan menginstal ulang node, yarn, git, dll. Hanya untuk memastikan tidak ada bisnis lucu di sana.

Terima kasih @ehowey untuk ⠙ source and transform nodes itu biasanya berarti harus mematikan terminal saya.

Jika saya menemukan sesuatu, saya akan memberi tahu Anda. Dan saya akan menonton utas ini juga.

@georgiee - terima kasih atas info --inspect. Saya akan melihat apakah saya bisa mendapatkan node debugging yang bekerja dengan WebStorm.

Saya juga menyukai gagasan Anda tentang reproduksi minimal. Tapi itu akan memakan waktu sementara saya memahami Gatsby sedikit lebih dalam.

Saat ini tergantung pada "node source and transform". Jarang, itu membuatnya ke createPagesStatefully dan hang di sana. Jika tidak, itu membangun secara normal.

Saat ini saya menghadapi masalah yang sama setelah melakukan "peningkatan benang" untuk memperbaiki ketergantungan yang rentan. Inilah pengaturan saya:

Sistem:
OS: macOS 10.15
CPU: (4) x64 Intel (R) Core (TM) i7-7567U CPU @ 3.50GHz
Kerangka: 5.7.1 - / bin / zsh
Binari:
Node: 12.8.1 - / usr / local / bin / node
Benang: 1.17.3 - / usr / local / bin / benang
npm: 6.10.3 - / usr / local / bin / npm
Bahasa:
Python: 2.7.16 - / usr / local / bin / python
Browser:
Chrome: 76.0.3809.132
Firefox: 68.0.2
Safari: 13.0.0
npmPackages:
gatsby: ^ 2.13.42 => 2.14.7
gatsby-background-image: ^ 0.8.3 => 0.8.6
gatsby-image: ^ 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
gatsby-komentar-gambar: ^ 3.1.10 => 3.1.19
gatsby-comment-relative-images-v2: ^ 0.1.5 => 0.1.5
gatsby-comment-responsive-iframe: ^ 2.2.5 => 2.2.10
gatsby-source-filesystem: ^ 2.1.6 => 2.1.18
gatsby-transformer-komentar: ^ 2.6.12 => 2.6.19
gatsby-transformer-sharp: ^ 2.2.5 => 2.2.12

Saat ini saya menghadapi masalah yang sama setelah melakukan "peningkatan benang" untuk memperbaiki ketergantungan yang rentan. Inilah pengaturan saya:

Pembaruan: Saya berhasil memperbaiki banyak hal dengan memulihkan file "yarn.lock" lama saya.

@ hendrawan._

Pembaruan: Saya berhasil memperbaiki banyak hal dengan memulihkan file "yarn.lock" lama saya.

Pengalaman saya adalah bahwa masalah dapat hilang tanpa alasan yang jelas hanya untuk kembali lagi nanti. Anda mungkin menemukan masalah kembali meskipun sudah memulihkan yarn.lock. Terus kabari kami.

Berikut ini reproduksi minimal menggunakan gatsby-starter-hello-world:

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

File kunci saat ini yang termasuk dalam repo adalah yang gagal untuk saya. Saya juga menyertakan salinan dalam repo yarn-working.lock dan yarn-notworking.lock . Semoga itu memudahkan seseorang untuk memecahkan masalah.

Lingkungan saya saat ini:

Sistem:
OS: macOS High Sierra 10.13.6
CPU: (2) x64 Intel (R) Core (TM) 2 Duo CPU P8600 @ 2.40GHz
Kerangka: 3.2.57 - / bin / bash
Binari:
Node: 10.16.3 - / usr / local / bin / node
Benang: 1.17.3 - / usr / local / bin / benang
npm: 6.10.3 - / usr / local / bin / npm
Bahasa:
Python: 2.7.10 - / usr / bin / python
Browser:
Chrome: 76.0.3809.132
Firefox: 67.0.2
Safari: 12.1.2
npmPackages:
gatsby: ^ 2.13.73 => 2.15.0
npmGlobalPackages:
gatsby-cli: 2.7.40

Saya mengalami masalah yang sama.

Beberapa arahan yang saya temukan:

1. Menurunkan gatsby-plugin-sitemap dari 2.2.9 menjadi 2.2.6 menyelesaikan masalah dengan yarn develop .

   • Aneh karena gatsby-plugin-sitemap seharusnya tidak mempengaruhi pembangunan pembangunan.

2. yarn build masih tidak berfungsi tetapi ketika saya menghapus gatsby-plugin-sitemap dari konfigurasi saya, yarn build berfungsi lagi.

@sharvit Saya dapat melaporkan bahwa ini tidak berhasil dalam kasus saya. Senang memperbaikinya untuk Anda, saya pikir itu ada hubungannya dengan file kunci dan beberapa masalah versi aneh jauh di dalam inti file kunci.

Saya telah berhasil kembali ke build yang berfungsi, sebagian besar waktu, mungkin 8/10 kali dengan kembali ke file kunci lama dan melakukan salin dan tempel. Saya sekarang juga dapat CTRL + C untuk memaksa keluar dari build jika macet yang tidak dapat saya lakukan pada satu titik dalam proses ini. Saya tidak tahu apa yang memperbaikinya di file kunci tetapi saya pikir petunjuknya ada di repositori yang saya posting di atas dengan dua salinan file kunci, yang berfungsi dan yang tidak. Ini adalah serangga yang aneh. Biasanya di komputer mendarat hal-hal yang meyakinkan bekerja atau tidak berfungsi.

@steinitz Adakah keberuntungan di pihak Anda? Saya memiliki apa yang Anda sebutkan terjadi. Tampaknya menjadi lebih baik, cukup bagus tetapi tidak sempurna dan sekarang hampir selalu gagal lagi. Cukup membuat frustrasi.

@tokopedia

Seperti yang Anda bayangkan, karena sifat masalah ini yang terus-menerus terjadi, saya ragu untuk melaporkannya. Inilah contoh kasusnya:

Setelah menghapus direktori node_modules, hapus yarn.lock lalu jalankan
npx yarn-upgrade-all
dan
yarn install
semuanya baik-baik saja.

Lalu, sekarang, sebagai tanggapan atas pesan Anda, saya mencoba
yarn start
Hasil: hang lagi di
source and transform nodes

Saya kira ada dua hal yang masuk akal untuk dilakukan:

1. mengambil @georgiee 's saran untuk mendapatkan Webstorm yang debugging bekerja dengan
   node --inspect dan lihat apakah saya dapat menemukan masalah yang jelas
2. sisihkan Gatsby sejenak untuk melihat apakah ada orang pintar yang memecahkan masalah

Memperbarui:

ctl-C menjalani proses macet di atas (yang tidak digunakan untuk menghentikan proses macet yang sangat mengganggu).
Kemudian yarn start terjebak di createPagesStatefully .
ctl-C lagi, yarn start - terjebak di source and transform nodes
ctl-C akan sekali lagi (untuk persetan) - kali ini yarn start berfungsi dan sedang berjalan

Tidak tahu harus berbuat apa, tapi itu dia.

Ini mirip dengan yang saya lihat, malam ini tampaknya lebih buruk mungkin membangun dengan sukses 1/10 kali atau kurang. Dari perspektif pemrograman / pengkodean, ini adalah perilaku yang sangat aneh. Secara anekdot tampaknya bekerja lebih baik beberapa hari lalu di 2.15.1 kemudian hari ini di 2.15.6. Saya juga bertanya-tanya kesamaan apa yang kita semua miliki yang menyebabkan bug ini terjadi. Dapatkah Anda menjalankan perintah gatsby info --clipboard dan mempostingnya?

Ini jelas tidak terlalu tersebar luas jika tidak akan ada banjir laporan tetapi juga bukan hanya saya seperti yang saya pikirkan. Kita semua tampaknya juga menggunakan benang, yang merupakan persyaratan bagi saya saat saya mengerjakan tema di ruang kerja benang. Saya masih dapat mereproduksi ini di gatsby-starter-hello-world jadi saya yakin ini adalah masalah ketergantungan atau konflik di file inti gatsby.

@ehowey inilah gatsby info Anda minta

Sistem:
OS: macOS 10.14.6
CPU: (4) x64 Intel (R) Core (TM) i7-5557U CPU @ 3.10GHz
Kerangka: 3.2.57 - / bin / bash
Binari:
Node: 12.9.1 - / usr / local / bin / node
Benang: 1.17.3 - / usr / local / bin / benang
npm: 6.11.2 - / usr / local / bin / npm
Bahasa:
Python: 2.7.16 - / usr / local / bin / python
Browser:
Chrome: 76.0.3809.132
Firefox: 68.0.1
Safari: 12.1.2
npmPackages:
gatsby: ^ 2.14.3 => 2.14.7
gatsby-image: ^ 2.2.14 => 2.2.15
gatsby-plugin-feed: ^ 2.3.9 => 2.3.9
gatsby-plugin-i18n: ^ 1.0.1 => 1.0.1
gatsby-plugin-less: ^ 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
gatsby-komentar-gambar: ^ 3.1.19 => 3.1.19
gatsby-comment-prismjs: ^ 3.3.9 => 3.3.9
gatsby-source-filesystem: ^ 2.1.18 => 2.1.18
gatsby-transformer-comments: ^ 2.6.19 => 2.6.19
gatsby-transformer-sharp: ^ 2.2.12 => 2.2.12
npmGlobalPackages:
gatsby-cli: 2.7.40

Saya mengalami masalah yang sama: situs dibuat dengan sempurna di Netlify, tetapi tergantung di mesin pengembangan saya dengan gatsby build dan gatsby develop .

Setelah bermain-main dengan versi paket, saya perhatikan bahwa mengembalikan gatsby-plugin-sitemap dari versi 2.2.10 ke 2.2.9 memperbaiki masalah bagi saya. Anehnya, beberapa orang di sini tampaknya memiliki masalah dengan 2.2.9, yang berarti masalahnya ada di tempat lain.

Edit: Berbicara terlalu cepat, Gatsby masih bergantung pada langkah "source and transform node" dan "createPagesStatefully", meskipun lebih jarang.

@goblindegook ini sepertinya pola umum dengan masalah khusus ini. Karena masalah datang dan pergi, tampaknya dengan cuaca, waktu, waktu sejak boot ... Anda dapat percaya sesuatu yang telah Anda lakukan telah memperbaikinya - hanya untuk mengulanginya.

Mengalami masalah ini juga, menurunkan gatsby-plugin-sitemap menjadi 2.2.6 dan tampaknya telah memperbaikinya

FWIW, saya juga mengalami ini tetapi tidak menggunakan yarn atau gatsby-plugin-sitemap .

gatsby info seandainya itu membantu:

  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

Bagi saya, membersihkan cache dengan gatsby clean menyelesaikan masalah.

Saya masih berburu, mencoba mencari tahu. Masih menjadi masalah bagiku. Adakah yang tahu jika ini mungkin berhubungan dengan peralihan dari babel 7.0.0 -> 7.5.5. Peralihan ini terjadi sekitar waktu saya mulai mengalami bug ini dan bertepatan dengan saya mulai melihat masalah ... Saya telah mencoba membuat resolusi benang berfungsi untuk mematok versi babel di 7.0.0 tetapi belum berhasil dengan ini belum.

Saya rasa saya dapat menawarkan beberapa wawasan - Saya mulai mengalami masalah ini ketika, setengah jalan menambahkan plugin ke sebuah proyek, saya memperbarui gatsby-cli di jendela terminal lain. Menjalankan gatsby clean dalam proyek saya berhasil.

dari https://github.com/gatsbyjs/gatsby/issues/6385#issuecomment -531949380 - Saya juga melihat masalah ini tetapi gatsby clean tidak menyelesaikannya. Sepertinya itu mungkin hanya hasil cetak CLI yang menggantung, itulah mengapa mengubah ukuran terminal memperbaikinya ?? 🤷‍♂ 😕 ❓❗️

Mengubah ukuran jendela terminal sepertinya dapat memperbaikinya bagi saya! Saya belum mengujinya secara super ekstensif, dapatkah beberapa orang lain yang mengalami masalah ini mencobanya juga? Sungguh bug yang aneh dan solusi yang berpotensi aneh.

Saya menghadapi masalah yang persis sama — gatsby sering macet di "node source and transform" atau "createPagesStatefully", dan saya _not_ menggunakan plugin sumber apa pun. Saya baru-baru ini menemukan perbaikan "ubah ukuran jendela terminal" dan saya 140% bingung tentang bagaimana sih ini memperbaikinya, tetapi ternyata berhasil. Ini sepertinya masalah yang cukup serius!

@JaKXz - Terima kasih! Ini membuatku gila. Perbaikannya tampaknya mengubah ukuran jendela terminal di VS Code. Cukup seret ke atas atau ke bawah sedikit dan tugas pengembangan berjalan lancar. Saya menguji dalam beberapa kasus berbeda baik benang maupun npm, ruang kerja dan bukan. Sepertinya bekerja dalam semua kasus itu bagi saya. Tampaknya juga macet atau hang di createPagesStatefully lebih sering daripada source and transform nodes sekarang untuk saya. Saya akan membiarkan masalah ini terbuka untuk saat ini, ini mungkin perlu diperbaiki dengan cara yang tidak terlalu "hacky" oleh seseorang yang lebih tahu caranya daripada saya.

@ehowey Saya memiliki masalah yang sama dan memindahkan jendela terminal di vscode berfungsi (tidak percaya saat membaca masalah ini sampai saya mencoba sendiri).
Apakah Anda tahu jika itu hanya terjadi pada VS Code?

Saya memiliki masalah ini di iTerm 2, jadi ini tidak spesifik VS Code.

Masalah saya juga ada di iTerm 2

Terminal badai web, Terminal Mac, iTerm

Apakah perbaikan terminal pengubah ukuran berfungsi untuk Anda semua di lingkungan pengembang yang berbeda?

Pada akhirnya, mengubah ukuran terminal berfungsi pada iTerm dan VSCode (mengambil beberapa percobaan untuk mereproduksi masalah pada iTerm)

Trik terminal pengubahan ukuran bekerja dengan andal untuk saya di iTerm 2.

Ya, mengubah ukuran iTerm 2 bekerja dengan sempurna

Jika pengubahan ukuran berhasil, saya curiga bug ini terkait dengan buffer, di suatu tempat membutuhkan stdout flush.

Jenis ini sepertinya masalah terkait kernel + shell. Mungkin beberapa cara node berinteraksi dengan kernel dan / atau shell Anda. Saya hanya mengatakan ini karena saya tidak dapat mereplikasi masalah menggunakan Linux atau Windows. Sepertinya saya tidak dapat menemukan masalah yang diketahui, jadi a) itu adalah beberapa kombinasi pola kode yang unik untuk Gatsby + interaksi dengan sistem, atau b) Saya belum tahu pertanyaan yang tepat untuk ditanyakan.

Jika mengubah ukuran terminal memperbaiki masalah, maka mungkin ada beberapa kesalahan dengan antara node dan kqueue menyebabkan pemblokiran di loop acara. Mengubah ukuran terminal mengirimkan proses sinyal SIGWINCH, yang menginterupsi loop peristiwa, yang membebaskannya dan memungkinkannya untuk melanjutkan.

Dapatkah Anda mencoba menjalankan kill -SIGWINCH ${pid} pada proses yang sedang berjalan saat macet? Harus bertindak sama seperti mengubah ukuran terminal.

Saya juga tertarik apakah ini terjadi di semua shell atau tidak. Berdasarkan informasi sejauh ini, ini telah gagal di bash dan zsh , dan ini mungkin salah satu faktor umum di antara semua emulator terminal. Bisakah kalian mencoba satu atau lebih dari sh , csh , ksh , tcsh , dll ...?

Jika masalah terjadi di semua shell, maka saya akan menebak bahwa itu adalah cara kernel menangani event loop node. Ini juga bisa menjadi alasan mengapa ini merupakan masalah intermiten. Jika beberapa fungsi mendapatkan waktu prosesor yang lebih sedikit (mungkin karena beban sistem variabel), itu mungkin memblokir terlalu lama, dan mungkin kernel mencoba menggunakan kembali node acara di suatu tempat, mengakibatkan kebuntuan? Saya tidak terlalu akrab dengan internal api, tapi saya yakin bahwa source and transform nodes cukup intensif sistem file IO. Itu berarti mungkin ada banyak pembongkaran yang terjadi, jadi siapa yang tahu apa yang sebenarnya terjadi di tingkat yang lebih rendah.

Saya pikir akan menjadi ide yang baik untuk mencoba mempersempit area permukaan kutu ini. Ini terjadi paling sering di source and transform nodes , sepertinya, jadi mungkin coba persempit ke plugin apa yang diblokir. Coba tambahkan baris berikut ke 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       })));

Kemudian jalankan node inspect node_modules/.bin/gatsby develop . Ini akan rusak segera setelah dimulai, jadi Anda harus menekan c saat Anda masuk ke prompt debug> , dan menunggu sampai berlanjut. Ketika istirahat pada yang debugger line, menulis exec console.log(plugin) , dan catatan apa yang dikatakan dalam resolve . Kemudian tekan c untuk melanjutkan. Lakukan ini sampai hang ... jika hang.

Karena sifat dari loop acara, saya yakin itu bahkan tidak akan hang saat debugging. Interupsi tersebut mungkin cukup untuk membuatnya tetap pada jalurnya. Bug Async bisa sangat merepotkan untuk dilacak. Jika tidak hang saat menggunakan debugger, ganti baris debugger dengan:

reporter.log(plugin.resolve);

Mudah-mudahan itu akan menghasilkan sesuatu. Alangkah baiknya melihat plugin apa yang menyebabkan pemblokiran. Jika kita bisa mengetahuinya, kita mungkin bisa mencari tahu apa yang perlu dioptimalkan / refactored untuk menyelesaikannya.

Mengubah ukuran juga berfungsi untuk saya, saya menggunakan zsh sebagai shell VSCode saya.

@ Js-Brecht - Terima kasih telah meluangkan waktu untuk tanggapan yang rinci. Saya tidak yakin di mana seharusnya saya memasukkan kill -SIGWINCH ${pid} . Saya tidak bisa melakukannya selama proses pembuatan.

Dengan debugger, kode berikut keluar ... di luar saya untuk memahaminya. Saya benar-benar terjebak di debugger tetapi .exit masih berfungsi.

⠋ 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, menggunakan Terminal, pengubahan ukuran berhasil untuk saya.

@ehowey Hanya supaya saya tahu saya memahami Anda dengan benar, itu gatsby-source-filesystem adalah pelakunya, yang masuk akal bagi saya ... terutama karena masalah gatsby yang sudah ada dan terkait.

Saya ingin melihat apakah plugin dapat menangani uji coba. Jika hang saat menjalankan tes, maka saya pikir itu akan menjadi cara mudah untuk melihat di mana gagal. Jika tidak, yah ... hanya perlu melakukan beberapa pembedahan / debugging, yang akan sulit bagi saya, karena saya tidak memiliki MacOS.

Dapatkah Anda mengunduh repo gatsby utama, dan menjalankan tes 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'

Juga, apakah Anda melakukan semua ini dengan repositori reproduksi minimal Anda? Saya melihat bahwa gatsby-plugin-mdx dijalankan dua kali, jadi itu memberi tahu saya bahwa ini bukan repositori barebones. Di dunia yang sempurna, itu seharusnya tidak menjadi masalah, tetapi saya pikir akan lebih baik menjalankan pengaturan sesederhana mungkin. Jika Anda tidak bisa membuatnya gagal secara andal dengan repo minimal, gunakan mana pun yang gagal paling konsisten (di tempat yang sama, setiap waktu (atau hampir))

😉

kill -SIGWINCH ${pid} harus dijalankan dari instance shell lain. Saat build macet, buka jendela / tab terminal lain, dan jalankan perintah dari sana. Potongan kecil ini seharusnya berfungsi:

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 }')

Jika ada kesalahan, coba jalankan perintah secara terpisah:

# 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

Jika Anda datang dengan tangan kosong setelah menjalankan tes, saya pikir akan berguna untuk memiliki core dump, sehingga kita bisa mendapatkan pelacakan tumpukan. Tapi, selangkah demi selangkah.

@ Js-Brecht Maaf atas respon lambat ... ini benar-benar hanya hobi sampingan yang saya lakukan di waktu senggang di malam hari.

Jadi saya menjalankan hal yang sama di dalam gatsby hello world starter - semaksimal mungkin. Maaf saya menjalankannya sebelumnya di ruang kerja utama saya pada proyek yang bermasalah dengan saya. Saya sebelumnya telah mereplikasi itu pada permulaan jadi saya tidak berpikir itu berkaitan dengan plugin tetapi lebih kepada sesuatu di inti gatsby.

Itu tergantung pada sumber dan mengubah node memberi saya output berikut:

< 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

Berikut ini dump dari perintah gatsby info jika itu berguna:

  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

Sebagai catatan tambahan - ketika saya menggunakan perintah debug Anda, itu tergantung pada sumber dan mengubah node. Saat saya menggunakan gatsby develop, sebagian besar tergantung di createPagesStatefully sekarang untuk saya. Maaf saya tahu ini sangat aneh. Sejujurnya saya tidak yakin berapa banyak pekerjaan yang berharga dari akhir hal Anda. Trik mengubah ukuran jendela terminal bekerja setiap saat untuk saya dan orang lain. Ini adalah perbaikan yang hacky tetapi tidak boleh memengaruhi banyak pengguna jika tidak, masalah akan membanjiri.

Ini sudah mulai terjadi di sini juga. _Resize the terminal_ trick menyelesaikannya; sangat aneh!

+1 Tidak berfungsi di iTerm2, tetapi berfungsi di Terminal 🤷‍♂️

@ehowey Mayoritas dari apa yang terjadi selama build ditentukan oleh satu plugin atau lainnya. Gatsby mengirim bersama mereka sebagai dependensi; Saya kira mereka bisa dianggap sebagai plugin inti. Inti Gatsby mengekspos API, yang mencari titik akhir yang ditentukan dalam plugin, dan meneruskannya serangkaian argumen yang mencakup tindakan / objek yang ditentukan dalam inti. Jadi ya, apa yang terjadi bisa saja terjadi di intinya, tetapi pertama-tama harus memanggil plugin, dan plugin tersebut menentukan konteks spesifik untuk API. Saya mencoba menentukan konteks yang menyebabkan build hang, dan juga perlu memverifikasi bahwa masalah tidak terjadi di plugin itu sendiri.

Bisakah saya membuat Anda mengubah baris ini?

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

Silakan jalankan ini, dan salin / tempel seluruh output (bahkan mungkin hanya melampirkannya ke tanggapan Anda sebagai file .txt ). Ini akan jauh lebih bertele-tele, dan banyak informasi mungkin tidak diperlukan, tetapi 🤷‍♂.

Setelah Anda selesai melakukannya, saya ingin melihat apakah meningkatkan kumpulan utas node membuat perbedaan. Saya telah memperhatikan masalah lain yang menyebutkan masalah yang sama atau serupa. Sebagian besar terjadi di source and transform , dan beberapa berbicara tentang tahap itu berlangsung selamanya, atau sepenuhnya terkunci. Jadi, saya ingin melihat apakah itu terjadi menjadi semacam kebuntuan di sistem file io ... akses sistem file asinkron diturunkan oleh node ke utas yang berbeda, dan, secara default, node hanya memiliki kumpulan 4 utas untuk ruang pengguna. Jika itu penuh, dan perlu melakukan pembongkaran lagi, tugas akan mengantri di loop acara utama, menunggu utas. Ini bisa, berpotensi, membuat seluruh program terhenti ... sampai utas tersedia. Gatsby memelihara cache pada sistem file, jadi mungkin ada tabrakan yang terjadi di suatu tempat, dan jika ada semacam kebuntuan yang terjadi, maka mungkin utas menunggu waktu tunggu / interupsi sebelum melanjutkan, dan jika ada lusinan (atau ratusan, bahkan) peristiwa akses sistem file, semuanya mungkin menunggu waktu tunggu yang sama, dan menyebabkan semuanya menumpuk. Anda dapat melihat bahwa ini dapat menyebabkan waktu tunggu bertambah lebih cepat.

Meningkatkan ukuran kolam mungkin membantu mengurangi beberapa lalu lintas ... atau, itu bisa terjadi dengan cara yang sama, hanya dengan lebih banyak utas 😆.
Coba perintah berikut:

UV_THREADPOOL_SIZE=10 gatsby develop

@ Js-Brecht Mengubah ukuran kumpulan benang tampaknya tidak membuat banyak perbedaan.
Saya mendapatkan output berikut dari perintah standar gatsby develop dengan perubahan yang Anda sebutkan di atas. Masih menggunakan starter gatsby hello-world dasar.

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

Ini adalah contoh di mana itu tergantung pada createPagesStatefully . Saya mendapatkannya untuk melanjutkan pembangunan dengan mengubah ukuran jendela terminal. Apakah internal-data-bridge peluang apa pun yang bisa menjadi pelakunya? Itu ditampilkan di kedua perintah yang Anda minta untuk saya jalankan sejauh ini.

Dapatkah Anda menunjukkan garis yang digantungkan?

createPagesStatefully dev-404-page

Saya tidak 100% yakin apakah bagian dev-404-page ada di sana tetapi tergantung pada contoh pertama createPagesStatefully

Terima kasih. Saya ingin mencoba beberapa perubahan lagi sekarang, jika Anda tidak keberatan.

Harap perbarui baris yang ditunjukkan pada file berikut:

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 => {

Saya curiga bahwa chokidar mungkin salah di sini. Itu ditingkatkan ke v3.x sekitar sebulan yang lalu, dan sepertinya mereka mulai menggunakan fsevents , atau mereka melakukan sesuatu yang menyebabkan beberapa perilaku keliru terkait dengan fsevents . Mereka memiliki beberapa masalah terbuka yang mirip dengan yang kita hadapi di sini, dengan simpul menggantung saat menggunakan chokidar.watch() . Ini sepertinya cocok, karena dilokalkan ke MacOS karena fsevents adalah proses Mac, dan build tampaknya gagal dalam modul tempat ia digunakan, atau dalam modul yang menulis / memproses file yang mungkin sedang ditonton.

chokidar.watch() ada di gatsby-source-filesystem , dan di situlah gagal dengan repo Anda yang lain, @ehowey; belum lagi, gatsby-source-filesystem tidak dipanggil dalam repo minimal Anda, yang menjelaskan mengapa berhasil melewati source and transform . Ada contoh chokidar sebelum internal-data-bridge , tapi saya pikir di lokasi yang tidak mempengaruhi build (misalnya query-watcher ). Namun, saya yakin internal-data-bridge adalah alasan mengapa ia terhenti saat menjalankan debugger; dan dalam proses langsung, hal itu kemungkinan memengaruhi tahap pembangunan selanjutnya.

Beri tahu saya jika ini memperbaiki masalah, atau bahkan jika hal itu membuatnya lebih baik dari sebelumnya. : crossed_fingers:

@ Js-Brecht Anda mendapatkan suatu tempat! Saya kehabisan gatsby develop mungkin 15 kali. Itu tidak pernah tergantung pada source and transform nodes atau createPagesStatefully tetapi tampaknya menggantung, mungkin 2/10 kali, pada start webpack server . Saya bisa menabrak ini bersama dengan trik terminal pengubah ukuran juga. Adakah kemungkinan Anda melewatkan contoh chokidar / fsevents yang terkait dengan start webpack server ?

Sebagai catatan tambahan, tampaknya juga bergerak melalui langkah-langkah proses pengembangan jauh lebih cepat daripada sebelumnya jika itu ada hubungannya dengan itu?

Itu sangat bagus untuk didengar. Saya sengaja meninggalkan satu instance chokidar, dan itu tepat setelah menyelesaikan bootstrap dan memulai server. Ada di node_modules/gatsby/dist/commands/develop.js menjelang akhir fungsi startServer() . Saya tidak berada di depan komputer sekarang, atau saya akan memberi Anda perbedaan.

Anda dapat menemukan baris yang tepat dengan melakukan:

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

Saya cukup yakin bahwa jika ini memperbaiki bootstrap, maka itu harus tetap digantung di server. Beri tahu saya jika perubahan itu membuatnya berjalan dengan andal, dan saya akan mengirimkan PR dan akan memberi tahu orang lain.

Saya sebenarnya tidak terkejut bahwa itu membuatnya berjalan lebih cepat. Membangun pada barebone proyek biasanya membawa saya mungkin kedua, dan saya melihat beberapa runtimes panjang gila untuk tahap tertentu dalam debug output Anda. fsevents seharusnya mempercepat, dan mengambil banyak beban dari cpu, tetapi ada sesuatu yang lucu terjadi yang membuatnya macet.

@ Js-Brecht Topi saya berangkat untuk Anda. Saya tidak tahu bagaimana Anda menarik kelinci itu keluar dari topi dan serangga memperbaiki yang aneh dari kejauhan tapi kerja bagus! Saya akan menunggu perbedaan untuk membuat perubahan menjadi develop.js karena saya tidak ingin mengubah hal yang salah, tetapi saya curiga itu akan memperbaikinya karena tergantung pada langkah terakhir ketika memulai server beberapa kali.

Inilah perbedaannya:

node_modules/gatsby/dist/commands/develop.js

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

Saya sangat menghargai bantuan Anda, menjalankan semua tes ini. Ini memang sulit, tetapi ini merupakan kesempatan untuk menggali internal MacOS, dan saya selalu menikmati mempelajari hal-hal baru: little_smiling_face:

Tolong beritahu saya bagaimana kelanjutannya; belum sepenuhnya keluar dari hutan: sweat_ smile :.

Bekerja! Saya baru saja menjalankan gatsby develop 10+ kali dan itu bekerja dengan sempurna. Terima kasih atas bantuan Anda dalam memeriksa masalah ini. Semoga ini menjadi peningkatan bagi kelompok kami yang mengalami ini!

Bagus! Di sini, sebentar lagi, ketika saya punya beberapa menit, saya akan mengumpulkan PR. Setelah selesai, Anda akan dapat menggunakan gatsby-dev-cli dengan repo saya sehingga Anda memiliki lingkungan pengembang yang berfungsi sampai tambalan diterbitkan (jika Anda tidak terbiasa dengan gatsby-dev-cli , saya bisa Tolong). Saya mungkin mencoba merekrut Anda untuk menguji perubahan, karena saya tidak memiliki OS yang tepat ... hal yang sama berlaku untuk semua orang di utas ini yang mengalami masalah ini.

Saya akan posting kembali di sini setelah selesai.

Saya menemukan masalah terpisah lain yang juga menyebabkan gejala ini - https://github.com/gatsbyjs/gatsby/issues/17935

Jika ada yang menggunakan LokiJS dan mengubah ukuran terminal tidak memperbaikinya, kemungkinan besar masalah yang saya temukan.

Hai teman-teman, @ehowey , silakan lihat PR # 17938. Jika ada yang mau menguji, silakan lakukan, dan tuliskan di PR.

Anda dapat mengambil repo saya, dan menggunakannya sebagai sumber gatsby di situs Anda dengan menggunakan gatsby-dev-cli . Pertama, Anda membutuhkan gatsby-dev-cli

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

Kemudian, cukup kloning repo, dan bootstrap.

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}"

Lalu pergi ke situs tempat Anda ingin menggunakan repo, dan jalankan gatsby-dev

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

dalam kasus saya, saya menggunakan OSX dan IntelliJ, saya harus:

• Tutup proyek di IntelliJ
• Coba lagi ( npm start )
• dan membuka kembali proyek di Intellij
  Saya kira masalah ini terkait dengan file pengindeksan IntelliJ

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

Adakah di antara kalian yang mau menguji # 17938?

Saya harus bisa melihatnya nanti malam ketika saya di rumah. Terima kasih atas semua pekerjaan Anda dalam hal ini!
Pada 1 Okt 2019, 10:23 AM -0600, Jeremy Albright [email protected] , menulis:

@steinitz, @rheinardkorf, @ hbthen3rd, @sharvit, @JaKXz, @emilyaviva, @MaximeHeckel
Adakah di antara kalian yang mau menguji # 17938?
-
Anda menerima ini karena Anda disebutkan.
Balas email ini secara langsung, lihat di GitHub, atau nonaktifkan utasnya.

Ada pembaruan tentang perbaikan untuk ini? Ini membeku di sumber dan mengubah node untuk saya dan teman saya juga setelah mencoba [Firebase Source] Fetching data for ...

Sayangnya, mengubah ukuran terminal tampaknya tidak memperbaikinya bagi kami

@ rishabhaggarwal2 Ada masalah serupa yang terdengar seperti yang Anda alami, yang akan hang saat mengambil data dari sumber online. Bisakah Anda mencoba menggunakan GATSBY_CONCURRENT_DOWNLOAD=10 gatsby develop ?

Melihat ini juga. Tidak dapat menjalankan gatsby develop secara lokal sama sekali pada permulaan lumen. Tetap tergantung pada createPageStatefully atau source and transform nodes

macOS Mojave 10.14.6
Gatsby CLI version 2.7.7
Gatsby version 2.14.1

Untuk orang lain yang menemukan masalah ini, coba

CHOKIDAR_USEPOLLING=1 gatsby develop

Itu harus menonaktifkan fsevents di MacOS, yang tampaknya merupakan solusi yang dapat diandalkan.

@ Js-Brecht Saya mengonfirmasi bahwa ini tampaknya memperbaikinya lebih permanen daripada solusi lain yang disebutkan di sini. Terima kasih telah berbagi.

@steinitz Anda mengatakan "lebih" secara permanen. Apakah Anda bermaksud mengatakan bahwa itu masih terjadi saat Anda menggunakan sakelar itu?

@ Js-Brecht Tidak, maaf belum jelas.

Saya menyinggung fakta bahwa solusi lain, termasuk solusi saya, tampaknya berfungsi untuk sementara waktu tetapi masalahnya kembali. Dengan solusi Anda, saya memprovokasi dengan membuat perubahan dan menjalankan kembali gatsby develop (dengan peningkatan Anda) tetapi build terus berfungsi.

Konon, ini adalah perjalanan rollercoaster jadi saya tetap secara emosional siap: tersenyum: agar masalahnya kembali.

Untuk memperjelas: sejauh ini, sangat bagus.

Ups, perbarui: Saya meluncurkan kembali WebStorm untuk tes terakhir sebelum memposting ini dan sekarang tergantung pada source and transform nodes di terminal WebStorm.

Untuk orang lain yang menemukan masalah ini, coba

CHOKIDAR_USEPOLLING=1 gatsby develop

Itu harus menonaktifkan fsevents di MacOS, yang tampaknya merupakan solusi yang dapat diandalkan.

@ Js-Brecht Saya menggunakan ubutu 18.04 dan terkadang saya mengalami masalah yang sama. Apakah ada saran untuk OS saya? Apakah Anda akan memberikan beberapa detail tentang kemungkinan penyebab masalah ini?

Ini telah diselesaikan berkat kerja rajin @ Js-Brecht dan @RomanHotsiy. Itu adalah masalah upstream di fsevents, jauh melampaui apa yang bisa saya pahami sendiri, dan harus diperbaiki di pembaruan mendatang setelah perubahan ini diterapkan dan bermigrasi dari fsevents ke gatsby itu sendiri. Untuk saat ini, solusi yang dapat diandalkan adalah mengubah ukuran jendela terminal, ada cara untuk memperbaikinya di repo Anda sendiri yang dibahas di sini: https://github.com/gatsbyjs/gatsby/pull/17938 namun Anda harus mengulanginya perbaiki setelah ada perubahan pada folder node_modules Anda dan mungkin tidak sepadan dengan pekerjaan tergantung pada seberapa sering Anda memperbarui versi paket Anda.

Saya akan membiarkan masalah terbuka sampai perbaikan bermigrasi ke hilir ke gatsby itu sendiri.

@ Boty22 Ubuntu tidak menggunakan fsevents , jadi mungkin ada sesuatu yang berbeda. Beberapa masalah telah ditemui saat mengambil data dari lokasi yang jauh; lihat # 6654 dan # 17940 untuk beberapa detail tentang memperbaiki masalah konkurensi.

Pertanyaan cepat: apakah mengubah ukuran terminal Anda membantu? Jika demikian, maka mungkin _something_ mirip dengan masalah ini.

@ Js-Brecht mengubah ukuran terminal tidak membantu untuk Ubuntu. Saya mengambil data dari tabel AirTable menggunakan plugin gatsby-source-airtable BTW

Itu bisa jadi masalahnya. Lihat komentar ini . Jika itu tidak berhasil, mungkin lebih baik membuka tiket baru

@steinitz maaf, saya melewatkan komentar Anda. Dapatkah Anda mencoba perbaikan yang dijelaskan dalam # 17938? Lebih khusus lagi, di sini dan di sini . Jika tidak berhasil, mungkin ada lebih banyak hal yang terjadi dalam kasus Anda.

Belum punya masalah dengan CHOKIDAR_USEPOLLING=1 gatsby develop sejak disebutkan.

Terima kasih atas penyelesaiannya @ Js-Brecht

Saya melihat ini juga dengan 2.15.28 ketika saya melakukan gatsby build. Apakah saya perlu menghentikan pengembangan gatsby di terminal lain? Ini terjadi sesekali

Terjadi lagi tanpa server dev berjalan. Saya punya blog sederhana dari mengikuti tutorial blog.

Tampaknya hampir setiap lari lainnya. Saya menggunakan Mac btw

@canvaspixels tidak mengubah ukuran jendela terminal https://github.com/gatsbyjs/gatsby/pull/17938#issuecomment -540661991

@RomanHoty yang memang menyortirnya! Terima kasih!

Halo semuanya, versi patch dari fsevents telah diterbitkan. Anda harus dapat dengan mudah menghapus file yarn.lock Anda, dan menjalankan thread lagi. Setiap dependensi Anda akan secara otomatis mengambil [email protected] , yang seharusnya menyelesaikan masalah.

Hati-hati - menghapus seluruh file yarn.lock juga dapat menyebabkan paket lain ditingkatkan.

Pilihan lain yang lebih tepat jika Anda menggunakan yarn adalah menghapus baris yang berkaitan dengan fsevents dalam yarn.lock dan menjalankan kembali yarn . Ini akan menyebabkan hanya paket yang terpengaruh untuk ditingkatkan. Jadi misalnya, saya menghapus baris berikut:

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

Cara lain untuk melakukan ini adalah menggunakan fitur resolutions dari Yarn (https://yarnpkg.com/lang/en/docs/selective-version-resolutions/). Dengan menambahkan yang berikut ini ke package.json dan kemudian menjalankan yarn , itu juga akan meningkatkan dependensi transitif dan memperbarui file yarn.lock :

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

Setelah Anda melakukan ini dan file kunci Anda diperbarui, Anda dapat menghapus properti resolutions dari package.json lagi.

Edit: versi petunjuk sebelumnya dihapus yang salah.

Anda juga dapat menjalankan yarn upgrade chokidar@latest . Itu harus membangun kembali file kunci dengan versi fsevents yang benar, tanpa menyentuh apa pun

Oh tunggu. Itu hanya jika Anda memiliki chokidar sebagai ketergantungan langsung 🙄. Lupa. @ karlhorky benar

Saya menggunakan npm . Menghapus node_modules , menjalankan npm i --save [email protected] dan kemudian npm i berhasil untuk saya. Butuh waktu 19-an untuk memulai dan saya menggunakan gatsby-lumen-starter sebagai basis.

- Edit:

Saya benar-benar menyelesaikan apa yang sedang saya kerjakan, didorong ke Netlify dan itu benar-benar tidak dapat dibangun karena fsevents ( error [email protected]: The platform 'linux' is incompatible with this module ).

Saya beralih ke yarn dan memiliki masalah yang sama jadi saya menghapus fsevents seluruhnya, dan sekarang lokal dan netlify keduanya berfungsi ...

Punya masalah yang sama dan tidak bisa melacak alasannya. Ini terjadi pada saya baik di mac dan pc. Bisa mencoba menghubungkan ini dengan kecepatan internet, namun ini juga terjadi pada saya ketika saya terhubung ke jaringan berkecepatan tinggi. Apa yang tampaknya berhasil untuk saya sekarang adalah menambahkan ini di env saya

GATSBY_CONCURRENT_DOWNLOAD=5

dan berjalan menggunakan --v8-pool-size=128

Dalam kasus saya, sepertinya firewall saya di osx. Jika saya cukup cepat untuk mengizinkan atau menolak koneksi yang datang dari luar, itu akan berhasil dengan sempurna. Masalahnya, dialog prompt muncul selama sepersekian detik dan menghilang saat Gatsby melanjutkan dan kemudian gagal tergantung pada salah satu dari banyak langkah yang disebutkan di atas.
Pilihan:

• nonaktifkan firewall (tidak memiliki itu)
• daftar putih Gatsby (tidak konsisten di seluruh proyek dan peningkatan)
• temukan cara untuk berhenti saat diminta sampai pengguna memilih opsi
• default alamat mengikat ke localhost (seharusnya tidak memerlukan prompt untuk menerima koneksi masuk).

@thomasthep Alamat mengikat default untuk server dev sudah localhost. Ia bahkan tidak mendengarkan koneksi eksternal kecuali Anda memintanya untuk menggunakan alamat IP Anda yang menghadap ke luar (atau 0.0.0.0). Dan bahkan kemudian, itu tidak memulai server dev sampai setelah bootstrap / build selesai. Jika itu adalah bootstrap yang menyebabkan prompt firewall, maka ini lebih berkaitan dengan plugin apa yang Anda gunakan, karena Gatsby tidak menjangkau internet dalam keadaan default-nya.

Bahkan seharusnya tidak ada koneksi "yang datang dari luar", secara umum; bahkan ketika plugin mengumpulkan informasi dari sumber eksternal, koneksi berasal dari host lokal Anda, bukan dari sumber eksternal, dan biasanya diterima sebagai "koneksi yang mapan" oleh sebagian besar firewall, menurut pengalaman saya, karena sebagian besar firewall dikonfigurasi untuk menerima koneksi keluar.

Saya dapat melihat ini terjadi jika firewall Anda dikonfigurasi untuk memblokir proses, bukan hanya koneksi. Dalam hal ini, Node-lah yang perlu dimasukkan ke dalam daftar putih.

Akan membutuhkan lebih banyak informasi untuk benar-benar memahami mengapa hal itu terjadi pada Anda. Mungkin akan lebih efektif untuk membuka tiket baru. Yang ini ada hubungannya dengan fsevents di MacOS yang menyebabkan masalah, dan itu telah diatasi, itulah mengapa sekarang ditutup. Apa pun yang tidak terkait dengan fsevents seharusnya memiliki masalahnya sendiri, untuk mendapatkan perhatian yang layak.

Sebagai catatan, ini juga dapat terjadi jika Anda menjalankan server GraphQL dalam mode debug dan berhenti pada titik putus.

Sebagai catatan: Ini mulai terjadi pada saya ketika saya menambahkan gatsby-source-s3-image dan keranjang s3 mencapai lebih dari 100 gambar. Ini melewati semua 145 gambar pada tahap source and transform nodes dan kemudian menggantung di sana selamanya. Ini masih terjadi, saya sudah mencoba perbaikan di atas. Untungnya, ini berfungsi setelah 5-6 kali percobaan jadi saya tidak diblokir.

Mengubah ukuran jendela terminal secara aneh berhasil untuk saya

Bagi saya, membatasi unduhan bersamaan seperti yang dijelaskan di sini sepertinya membantu.

Saya menambahkan baris berikut ke file .env saya. Standarnya adalah 200.
GATSBY_CONCURRENT_DOWNLOAD=50

Tidak yakin apakah itu menyelesaikan masalah Anda tetapi mungkin itu membantu seseorang :)

@ rishabhaggarwal2 Ada masalah serupa yang terdengar seperti yang Anda alami, yang akan hang saat mengambil data dari sumber online. Bisakah Anda mencoba menggunakan GATSBY_CONCURRENT_DOWNLOAD=10 gatsby develop ?

Terima kasih, ini memperbaikinya untuk saya. Karena saya menarik banyak konten dari situs web pihak ketiga, ia terus mengunduh konten. (97% - hampir sejauh ini)