Gatsby: [ошибка fsevents] Застрял в «узлах источника и преобразования» / «createPagesStatefully» в MacOS

Обновлено - я тестировал комментирование файла gatsby-node.js, и один раз сборка прогрессировала, но затем я попробовал еще раз и сделал это, и он снова застрял на том же месте.

Есть ли шанс, что это связано с тем, что мой старый компьютер Macbook Pro 2010 года (обновленный до 8 ГБ оперативной памяти и SSD) еще не остановил меня, но я знаю, что его дни ограничены. Для меня это хобби, и у меня есть маленькие дети, поэтому денег на новый компьютер не было, так как он отлично работал с обновленными RAM и SSD.

Я попытался вернуться к gatsby 2.13.52, который был последней версией, на которой я работал стабильно, я также пытался вернуться к 16.8.6.

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

Я также могу, изредка, по непонятной причине заставить его строить нормально. Кажется, что это не рифма или причина. Я потратил пару часов на поиск закономерностей или ошибок, которые могли вызывать это, но ничего не нашел. Я просмотрел https://github.com/gatsbyjs/gatsby/issues/6654 и безрезультатно попробовал некоторые элементы.

Это одна из самых странных ошибок, с которыми я когда-либо сталкивался, потому что поведение, кажется, меняется без заметных изменений в коде. В некоторых случаях сборка зависает на узлах источника и преобразования (60% времени), в некоторых случаях зависает при создании страниц с сохранением состояния (20%), в некоторых случаях сборка выполняется успешно (20%). Я заставил его отображать все три поведения без изменения строчки кода.

Я воспроизвел это поведение и в gatsby-starter-blog, что действительно странно. Опять же, это заставляет меня думать, что это проблема с моей стороны на местном уровне. Что интересно, зависает только на createPagesStatefully .

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

Вот список того, что я пробовал до сих пор:

• Смена версии узла, пробовала 12, 10 и 8

• Возвращаясь к предыдущему моменту в моей истории коммитов, который работал - он все еще не работает.

• Комментируем плагины и области gatsby-config

• Комментирую содержимое моего gatsby-node.js

• Протестируйте его еще раз на Netlify, он все еще успешно построен, поэтому я думаю, что он должен иметь какое-то отношение к моему компьютеру.

• Удаление 4 страниц в моем каталоге src / pages и размещение очень простого файла index.mdx

• Удаление всех файлов node_module и lock, переустановка

• Перезагрузка компьютера

• Создание нового рабочего пространства с новыми клонами темы / стартера из Github.

• Тестирование блога gatsby-starter, поведение похоже, но зависает на createPagesStatefully

Здравствуйте,

Я мало что могу сделать, но могу подтвердить, что вижу эту проблему у нескольких стартеров Gatsby. И, как вы указываете, иногда он просто решает построить или прекратить сборку, зависая либо на «узлах источника и преобразования», либо на createPagesStatefully.

Довольно расстраивает и приводит к самым возмутительным попыткам исправить это.

Я не был свидетелем этой проблемы, но это звучит неловко, и мне действительно хотелось бы узнать причину такого поведения с вашей стороны.

Подготовка
Вы должны попытаться использовать отладчик узлов, чтобы добраться до корня проблемы. Задача в вашем package.json будет выглядеть так. Если вы используете VSCode, вы можете включить «Auto Attach», чтобы использовать внутренний отладчик вместе с этой задачей (убедитесь, что вы используете внутренний терминал для этой цели)

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

Отладка, конечно же, будет работать с любой IDE, просто убедитесь, что вы правильно подключили отладчик.

1. Вариант: минимальная воспроизводимость.
Вы упомянули createPagesStatefully как источник проблемы. Если вы уверены, что это источник проблемы, возможно, вы могли бы создать очень крошечный проект, чтобы воспроизвести его. Откажитесь от всего начального, просто используйте gatsby напрямую и используйте от createPagesStatefully до gatsby-node.js с некоторыми примерами, имитирующими действия ваших начинающих. Затем запустите gatsby и отлаживайте его через node inspect.

Так вы сможете найти, где он висит.

2. Альтернатива: внутри вашего проекта / стартера
Конечно, вы можете попытаться отладить проблему внутри своего проекта с помощью той же техники. Но, возможно, у вас есть несколько проблем, которые накладываются друг на друга и размывают ваше представление о причине проблем. Поэтому я всегда старался получить минимальное воспроизведение перед началом отладки.

Удачи.

Итак ... Я столкнулся со странным поведением файлов блокировки. Может быть, кто-нибудь, кто знает больше, может указать мне правильное направление. Пытаясь получить минимальную рабочую сборку, я в основном отказался от установки Gatsby «привет, мир», но она все еще не работала, что было действительно странно.

Что еще более странно, так это то, что настоящий gatsby-starter-hello-world действительно работает и строится на моем компьютере. НО ... если я удалю файл блокировки и получу пряжу для восстановления нового файла блокировки, тогда сборка начнет давать сбой, зависать на узлах источника и преобразования. Я мог бы получить мою урезанную и минимальную реализацию для сборки, если бы я скопировал файл блокировки из «hello-world» и использовал его. Итак, моя текущая теория заключается в том, что в моих файлах блокировки есть какая-то проблема с версией, которая вызывает эту проблему, но я застрял здесь.

Я также удалил все свои домашние установки и переустановил node, yarn, git и т. Д. Просто чтобы убедиться, что это не какой-то забавный бизнес.

Спасибо @ehowey за то, что подняли этот вопрос .... Я думал, что это только я, потому что это довольно прерывисто (но случается более чем в 50% случаев). Сделал то же самое, что и вы, чтобы попытаться отладить ситуацию. Когда я вешаю на ⠙ source and transform nodes это обычно означает, что мне нужно убить мой терминал.

Если найду что-нибудь, дам тебе знать. И я тоже посмотрю эту ветку.

@georgiee - спасибо за информацию --inspect. Я собираюсь посмотреть, смогу ли я заставить отладку узлов работать с WebStorm.

Мне также нравится твоя идея минимального воспроизведения. Но это займет время, пока я пойму Гэтсби немного глубже.

В настоящее время он висит на «узлах источника и преобразования». Редко он попадает в createPagesStatefully и там зависает. В остальном строится нормально.

В настоящее время я сталкиваюсь с той же проблемой после выполнения «обновления пряжи», чтобы исправить уязвимую зависимость. Вот моя установка:

Система:
ОС: macOS 10.15
Процессор: (4) x64 Intel (R) Core (TM) i7-7567U CPU @ 3,50 ГГц
Оболочка: 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
Safari: 13.0
npmPackages:
Гэтсби: ^ 2.13.42 => 2.14.7
Гэтсби-фон-изображение: ^ 0.8.3 => 0.8.6
gatsby-изображение: ^ 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-реагировать-шлем: ^ 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-замечание-изображения: ^ 3.1.10 => 3.1.19
Гэтсби-замечание-относительные-изображения-v2: ^ 0.1.5 => 0.1.5
gatsby-комментарий-отзывчивый-iframe: ^ 2.2.5 => 2.2.10
исходная файловая система gatsby: ^ 2.1.6 => 2.1.18
Замечание-трансформер Гэтсби: ^ 2.6.12 => 2.6.19
Гэтсби-трансформатор-резкий: ^ 2.2.5 => 2.2.12

В настоящее время я сталкиваюсь с той же проблемой после выполнения «обновления пряжи», чтобы исправить уязвимую зависимость. Вот моя установка:

Обновление: мне удалось исправить ситуацию, восстановив мой старый файл «yarn.lock».

@ hbthen3rd

Обновление: мне удалось исправить ситуацию, восстановив мой старый файл «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
Процессор: (2) x64 Intel (R) Core (TM) 2 Duo CPU P8600 @ 2,40 ГГц
Оболочка: 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
npmPackages:
Гэтсби: ^ 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 Могу сообщить, что в моем случае это не сработало. Рад, что он исправил это для вас, я действительно думаю, что в конечном итоге это как-то связано с файлами блокировки и какой-то странной проблемой с версией глубоко в недрах файла блокировки.

Мне удавалось вернуться к работающей сборке, большую часть времени, может быть, 8/10 раз, вернувшись к старому файлу блокировки и сделав некоторое копирование и вставку. Теперь я могу также CTRL + C, чтобы принудительно завершить сборку, если она зависает, чего я не мог сделать в какой-то момент в этом процессе. Я не знаю, что исправляет это в файле блокировки, но я думаю, что подсказки находятся в репозитории, который я опубликовал выше, с двумя копиями файла блокировки, одна из которых работает, а другая - нет. Это странный зверь из насекомых. Обычно в компьютерной сфере что-то надежно работает или не работает.

@steinitz Удачи на твоей

@ehowey

Как вы можете себе представить, из-за того, что эта проблема постоянно повторяется, я не решаюсь сообщить об этом. Вот показательный пример:

После удаления каталога node_modules, удаления yarn.lock и запуска
npx yarn-upgrade-all
и
yarn install
все было хорошо.

Тогда, прямо сейчас, в ответ на ваше сообщение, я попробовал
yarn start
Результат: снова зависает на
source and transform nodes

Я полагаю, есть две разумные вещи:

1. принять @georgiee «ы советы , чтобы получить WebStorm это отладки работы с
   node --inspect и посмотрим, смогу ли я обнаружить очевидные проблемы
2. отложите на время Гэтсби, чтобы посмотреть, решит ли проблему какой-нибудь умный человек

Обновить:

ctl-C отключил вышеуказанный зависший процесс (который не использовался для остановки зависшего процесса, что вдвойне раздражало).
Затем 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
Процессор: (4) x64 Intel (R) Core (TM) i7-5557U CPU @ 3,10 ГГц
Оболочка: 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
npmPackages:
Гэтсби: ^ 2.14.3 => 2.14.7
gatsby-изображение: ^ 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-реагировать-шлем: ^ 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-замечание-изображения: ^ 3.1.19 => 3.1.19
Гэтсби-замечание-призма: ^ 3.3.9 => 3.3.9
исходная файловая система gatsby: ^ 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 .

Поигравшись с версиями пакетов, я заметил, что возврат gatsby-plugin-sitemap с версии 2.2.10 на 2.2.9 устранил проблему для меня. Как ни странно, у некоторых людей здесь, похоже, есть проблемы с 2.2.9, что может означать, что проблема находится в другом месте.

Изменить: сказано слишком рано, Гэтсби все еще зависает на этапах «источник и преобразование» и «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 решила проблему.

Я все еще охотюсь, пытаясь понять это. Все еще проблема для меня. Кто-нибудь знает, может ли это относиться к переключению с babel 7.0.0 -> 7.5.5. Это переключение произошло примерно в то время, когда я начал испытывать эту ошибку, и совпадает с тем, что я начинаю видеть проблемы ... Я пытался заставить работать разрешения пряжи, чтобы привязать версии babel к 7.0.0, но не добился успеха с этого пока нет.

Я думаю, что могу предложить некоторую информацию - у меня возникла эта проблема, когда на полпути к добавлению плагинов в проект я обновил gatsby-cli в другом окне терминала. Запуск gatsby clean в моем проекте сработал.

из https://github.com/gatsbyjs/gatsby/issues/6385#issuecomment -531949380 - Я также вижу эту проблему, но gatsby clean не решил ее. Кажется, что это может быть просто распечатка CLI, поэтому изменение размера терминала исправляет это? 🤷‍♂ 😕 ❓❗️

Изменение размера окна терминала, похоже, исправляет это для меня! Я не тестировал его очень тщательно, могут ли другие люди, у которых есть эта проблема, попробовать это? Какая странная ошибка и потенциально странное решение.

Я сталкиваюсь с той же проблемой - Гэтсби часто застревает на «узлах источника и преобразования» или «createPagesStatefully», и я _не_ использую какие-либо плагины исходного кода. Я только недавно столкнулся с исправлением «изменить размер окна терминала» и на 140% озадачен тем, как, черт возьми, это исправляет, но это так. Это кажется довольно серьезной проблемой!

@JaKXz - Спасибо! Это сводило меня с ума. Исправление похоже на изменение размера окна терминала в VS Code. Просто перетащите его немного вверх или вниз, и задача разработки будет успешно продолжена. Я тестировал в нескольких разных случаях как yarn, так и npm, рабочие области и нет. Похоже, что все эти дела у меня сработали. Кроме того, мне кажется, что на createPagesStatefully зависает чаще, чем source and transform nodes . Я собираюсь пока оставить эту проблему открытой, возможно, ее нужно будет исправить менее «хакерским» способом, кем-то, у кого больше знаний, чем у меня.

@ehowey У меня такая же проблема, и перемещение окна терминала в vscode работает (не мог поверить в это при чтении этой проблемы, пока не попробовал себя).
Вы знаете, происходит ли это только на VS Code?

У меня есть эта проблема с iTerm 2, поэтому она не связана с VS Code.

Моя проблема также была в iTerm 2

Терминал Webstorm, Терминал Mac, iTerm

Сработало ли исправление терминала изменения размера для всех вас в разных средах разработки?

С моей стороны, изменение размера терминала работало на iTerm и VSCode (потребовалось несколько попыток, чтобы воспроизвести проблему на iTerm)

Трюк с изменением размера терминала у меня надежно работает в iTerm 2.

Да, изменение размера iTerm 2 работает отлично

Если изменение размера работает, я подозреваю, что эта ошибка связана с буфером, где-то требуется stdout flush.

Это похоже на проблему, связанную с ядром + оболочкой. Вероятно, каким-то образом узел взаимодействует с вашим ядром и / или вашей оболочкой. Я говорю это только потому, что не могу воспроизвести проблемы с помощью Linux или Windows. Кажется, я не могу найти никаких известных проблем, поэтому либо а) это какая-то комбинация шаблонов кода, уникальная для Гэтсби + взаимодействие с системой, либо б) я просто еще не знаю, какой вопрос задать.

Если изменение размера терминала устраняет проблему, то это может быть сбой между узлом и kqueue вызывающий блок в цикле событий. Изменение размера терминала отправляет процессу сигнал SIGWINCH, который прерывает цикл обработки событий, освобождая его и позволяя продолжить.

Можете ли вы попробовать запустить kill -SIGWINCH ${pid} в запущенном процессе, когда он зависает? Должен действовать так же, как изменение размера терминала.

Еще меня интересует, происходит ли это во всех оболочках. Судя по имеющейся на данный момент информации, это не удалось в bash и zsh , и, вероятно, это один из общих факторов между всеми эмуляторами терминала. Ребята, можете ли вы попробовать одно или несколько из sh , csh , ksh , tcsh и т. Д.?

Если проблема возникает во всех оболочках, я бы предположил, что так ядро ​​обрабатывает цикл событий узла. Это также может быть причиной того, что это временная проблема. Если какая-то функция получает меньше процессорного времени (возможно, из-за переменной загрузки системы), она может блокироваться слишком долго, и, возможно, ядро ​​пытается где-то повторно использовать узел события, что приводит к тупиковой ситуации? Я не очень хорошо знаком с внутренним устройством api, но держу пари, что source and transform nodes довольно интенсивно вводит-вывод файловой системы. Это означает, что, вероятно, происходит большая разгрузка, так что кто знает, что на самом деле происходит на более низких уровнях.

Я думаю, что было бы неплохо попытаться сузить область поверхности этой ошибки. Похоже, это чаще всего встречается в 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 и запустить тесты 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 - настолько голым, насколько это возможно. Извините, я запускал его раньше в своей основной рабочей области над проектом, с которым у меня возникли проблемы. Я ранее воспроизводил его на стартерах, поэтому я не думаю, что это связано с плагином, а скорее с чем-то в ядре Gatsby.

Он зависает на узлах источника и преобразования, давая мне следующий результат:

< 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 development, для меня он в основном висит на createPagesStatefully. Извините, я знаю, что это действительно странно. Честно говоря, я не уверен, сколько это стоит работы с вашей стороны. Уловка с изменением размера окна терминала работает каждый раз для меня и других. Это хакерское исправление, но оно не должно влиять на многих пользователей, иначе проблемы будут затоплены.

Это начало происходить и здесь. Уловка с _resize терминала_ решает эту проблему; очень странно!

+1 Не работает в iTerm2, но работает в Терминале 🤷‍♂️

@ehowey Большая часть того, что происходит во время сборки, определяется тем или иным плагином. Гэтсби поставляется с ними в качестве зависимостей; Полагаю, их можно считать основными плагинами. Ядро 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 потоков для пользовательского пространства. Если они заполнятся, и потребуется дополнительная разгрузка, задачи будут помещены в очередь в основном цикле событий, ожидая потока. Это потенциально может привести к остановке всей программы ... до тех пор, пока поток не станет доступным. Гэтсби поддерживает кеш в файловой системе, поэтому, возможно, где-то происходит коллизия, и если происходит какая-то тупиковая ситуация, то, возможно, потоки ждут тайм-аута / прерывания, прежде чем двигаться дальше, и если их десятки (или даже сотни) событий доступа к файловой системе, все они могут ждать одного и того же тайм-аута и вызывать накопление всего. Вы можете видеть, что это может привести к довольно быстрому увеличению времени ожидания.

Увеличение размера пула может помочь облегчить часть трафика ... или это может произойти точно так же, только с большим количеством потоков 😆.
Попробуйте следующую команду:

UV_THREADPOOL_SIZE=10 gatsby develop

@ Js-Brecht Изменение размера пула потоков, похоже, не имело большого значения.
Я получаю следующий результат стандартной команды gatsby develop с изменениями, которые вы упомянули выше. По-прежнему на базовом стартере hello-world, gatsby.

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

Я не уверен на 100%, была ли там часть dev-404-page но она зависла на первом экземпляре 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() . Кажется, это подходит, поскольку он локализован для MacOS из-за того, что fsevents является процессом Mac, и сборка, похоже, не работает в модулях, где она используется, или в модулях, которые записывают / обрабатывают файлы которые, вероятно, наблюдаются.

chokidar.watch() тоже существует в gatsby-source-filesystem , и именно здесь он терпит неудачу с другим вашим репо, @ehowey; не говоря уже о том, что gatsby-source-filesystem не вызывается в вашем минимальном репо, что объясняет, почему он проходит мимо source and transform . Есть экземпляры chokidar перед internal-data-bridge , но я думаю, что в местах, которые не влияют на сборку (например, query-watcher ). Однако я считаю, что internal-data-bridge является причиной зависания во время работы отладчика; и при прямом запуске это, вероятно, повлияло на более поздние этапы сборки.

Сообщите мне, устранит ли это проблемы или даже продвинется дальше, чем раньше. :скрещенные пальцы:

@ Js-Brecht Вы куда-то идете! Я запускал gatsby develop наверное, 15 раз. Он никогда не зависал на source and transform nodes или createPagesStatefully но, похоже, зависал, может быть, 2/10 раз, на start webpack server . Я мог бы использовать это вместе с трюком с терминалом изменения размера. Есть ли шанс, что вы пропустили экземпляр chokidar / fsevents, относящийся к start webpack server ?

В качестве побочного примечания также казалось, что шаги процесса разработки проходили намного быстрее, чем раньше, если это имеет к этому какое-то отношение?

Это действительно приятно слышать. Я специально оставил один экземпляр chokidar, и это сразу после того, как он завершит загрузку и запустит сервер. Он находится в node_modules/gatsby/dist/commands/develop.js ближе к концу функции startServer() . Я сейчас не за компьютером, иначе я бы дал вам разницу.

Вы можете найти точную строку, выполнив:

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

Я был почти уверен, что если это исправит загрузку, она все равно зависнет на сервере. Сообщите мне, если это изменится, и я сделаю это, и я напишу PR и позабочусь о том, чтобы люди знали.

На самом деле я не удивлен, что он заставляет его работать быстрее. Сборка на основе проекта barebones обычно занимает у меня, может быть, секунду, и я видел сумасшедшие длительные сроки выполнения для определенных этапов в ваших отладочных выводах. fsevents должен ускорить процесс и снять большую нагрузку с процессора, но вместо этого происходит что-то забавное, из-за чего он застревает.

@ 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, и мне всегда нравится узнавать что-то новое: слегка_smiling_face:

Пожалуйста, дайте мне знать, как это происходит; еще не совсем из леса: sweat_ smile :.

Работает! Я просто запустил gatsby develop 10+ раз, и это сработало безупречно. Спасибо за вашу помощь в изучении этого вопроса. Надеюсь, это улучшит нашу группу, испытывающую это!

Большой! Здесь через некоторое время, когда у меня будет пара минут, я сделаю пиар. Как только это будет сделано, вы сможете использовать gatsby-dev-cli с моим репо, чтобы у вас была рабочая среда разработки до публикации патча (если вы не знакомы с gatsby-dev-cli , я могу Помогите). Я мог бы попытаться нанять вас для проверки изменений, так как у меня нет подходящей ОС ... то же самое касается всех остальных в этой ветке, испытывающих эту проблему.

Я отправлю сюда ответ, когда это будет сделано.

Я обнаружил еще одну отдельную проблему, которая также вызывает этот симптом - https://github.com/gatsbyjs/gatsby/issues/17935

Если кто-то использует LokiJS и изменение размера терминала не решает этого, скорее всего, это проблема, которую я обнаружил.

Привет, ребята, @ehowey , пожалуйста, проверьте PR № 17938. Если кто-то хочет протестировать, пожалуйста, сделайте это и напишите о PR.

Вы можете поймать мое репо и использовать его в качестве источника gatsby на своем сайте, используя gatsby-dev-cli . Во-первых, вам нужно 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?

Я смогу посмотреть сегодня вечером, когда буду дома. Спасибо за всю вашу работу!
1 октября 2019 г., 10:23 -0600, Джереми Олбрайт [email protected] написал:

@steinitz , @rheinardkorf , @ hbthen3rd , @sharvit , @JaKXz , @emilyaviva , @MaximeHeckel
Кто-нибудь из вас желает протестировать № 17938?
-
Вы получаете это, потому что вас упомянули.
Ответьте на это письмо напрямую, просмотрите его на GitHub или отключите обсуждение.

Есть какие-нибудь обновления для исправления этого? Он зависает в узлах источника и преобразования для меня и моего друга после того, как он попробовал [Firebase Source] Fetching data for ...

К сожалению, изменение размера терминала не решает эту проблему.

@ rishabhaggarwal2 Есть похожая проблема, которая, похоже, может быть тем, с чем вы столкнулись, когда она зависает при извлечении данных из онлайн-источника. Можете попробовать использовать GATSBY_CONCURRENT_DOWNLOAD=10 gatsby develop ?

Видя это тоже. Не удается запустить gatsby develop локально при запуске lumen. Держится на 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

Это должно отключить fsevents в MacOS, что кажется надежным решением.

@ Js-Brecht Я подтверждаю, что, похоже, он исправляет это более надолго, чем другие упомянутые здесь обходные пути. Спасибо, что поделился.

@steinitz вы постоянно говорите «больше». Вы хотите сказать, что это все еще происходит, когда вы используете этот переключатель?

@ Js-Brecht Нет, извините за неясность.

Я имел в виду тот факт, что другие обходные пути, включая мой собственный, какое-то время работали, но проблема вернулась. С вашим решением я спровоцировал это, внося изменения и повторно запустив gatsby develop (с вашими улучшениями), но сборка продолжает работать.

Тем не менее, это была поездка на американских горках, поэтому я остаюсь эмоционально подготовленным: smile: к тому, что проблема вернется.

Для ясности: пока все хорошо.

К сожалению, обновление: я перезапустил WebStorm для заключительного теста перед публикацией, и теперь он висит на source and transform nodes в терминале WebStorm.

Если кто-то еще обнаружит эту проблему, попробуйте

CHOKIDAR_USEPOLLING=1 gatsby develop

Это должно отключить fsevents в MacOS, что кажется надежным решением.

@ Js-Brecht Я использую ubutu 18.04 и иногда сталкиваюсь с той же проблемой. Есть ли какие-нибудь предложения для моей ОС? Не могли бы вы подробнее рассказать о возможных причинах этой проблемы?

Эта проблема была решена благодаря кропотливой работе @ Js-Brecht и @RomanHotsiy. Это проблема апстрима в fsevents, выходящая за рамки того, что я мог решить самостоятельно, и ее следует исправить в будущих обновлениях, как только эти изменения будут реализованы и перенесены из fsevents в сам gatsby. На данный момент надежным обходным путем является изменение размера окна терминала, есть способ исправить это в самом вашем репо, который обсуждается здесь: https://github.com/gatsbyjs/gatsby/pull/17938, однако вам придется переделать это исправить после любых изменений в вашей папке node_modules и может не стоить работы в зависимости от того, как часто вы обновляете версии пакетов.

Я оставлю проблему открытой до тех пор, пока исправление не будет перенесено в сам gatsby.

@ Boty22 Ubuntu не использует fsevents , так что, вероятно, это что-то другое. При получении данных из удаленного места возникли некоторые проблемы; см. # 6654 и # 17940 для получения дополнительной информации об устранении проблем параллелизма.

Быстрый вопрос: помогает ли изменение размера вашего терминала? Если да, то это может быть _ что-то_ похожее на эту проблему.

@ Js-Brecht изменение размера терминала не помогает Ubuntu. Я получаю данные из таблицы AirTable, используя плагин gatsby-source-airtable BTW

Это могло быть проблемой. Посмотрите этот комментарий . Если это не сработает, возможно, лучше открыть новый билет

@steinitz извините, я пропустил ваш комментарий. Можете попробовать исправление, описанное в # 17938? Точнее здесь и здесь . Если это не сработает, то, вероятно, в вашем случае происходит нечто большее.

С момента упоминания не было никаких проблем с CHOKIDAR_USEPOLLING=1 gatsby develop .

Спасибо за обходной путь @ Js-Brecht

Я тоже это вижу в версии 2.15.28, когда делаю сборку gatsby. Нужно ли мне остановить разработку Gatsby в другом терминале? Это периодически происходит

Произошло снова без запущенного сервера разработки. У меня есть простой блог, следуя руководству по блогу.

Вроде бы почти каждый второй запуск. Я на Mac, кстати

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

Другой способ сделать это - использовать функцию resolutions в Yarn (https://yarnpkg.com/lang/en/docs/selective-version-resolutions/). Добавив следующее в ваш package.json а затем запустив yarn , он также обновит транзитивные зависимости и обновит ваш файл yarn.lock :

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

После того, как вы это сделаете и ваш файл блокировки будет обновлен, вы можете снова удалить свойство resolutions из package.json .

Edit: удалена предыдущая, некорректная версия инструкций.

Вы также можете запустить yarn upgrade chokidar@latest . Это должно восстановить файл блокировки с правильной версией fsevents, не касаясь чего-либо еще

Ой, подожди. Это только если у вас есть чокидар как прямая зависимость 🙄. Забыл. @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, так и на ПК. Можно попытаться связать это со скоростью интернета, но это случилось со мной также, когда я был подключен к высокоскоростной сети. Что, похоже, сейчас работает для меня, так это добавить это в свой env

GATSBY_CONCURRENT_DOWNLOAD=5

и работает с использованием --v8-pool-size=128

В моем случае это похоже на приглашение моего брандмауэра на osx. Если я буду достаточно быстрым, чтобы разрешить или запретить подключения извне, все пройдет безупречно. Проблема в том, что диалоговое окно с запросом появляется на долю секунды и исчезает, когда Гэтсби продолжает работу, а затем не может зависнуть на одном из многих шагов, упомянутых выше.
Параметры:

• отключить брандмауэр (его нет)
• добавить Гэтсби в белый список (не согласовано между проектами и обновлениями)
• найти способ остановиться при появлении запроса, пока пользователь не выберет вариант
• адрес привязки по умолчанию к localhost (не должен требовать приглашения принимать входящие соединения).

@thomasthep Адрес привязки по умолчанию для сервера разработки уже localhost. Он даже не прослушивает внешние соединения, если вы не укажете ему использовать ваш внешний IP-адрес (или 0.0.0.0). И даже тогда он не запускает сервер разработки до тех пор, пока не будет завершена загрузка / сборка. Если запрос брандмауэра вызван загрузкой, то это больше связано с тем, какие плагины вы используете, потому что Gatsby не обращается к Интернету в своем состоянии по умолчанию.

Никаких связей "извне" вообще быть не должно, вообще говоря; даже когда плагин собирает информацию из внешнего источника, соединение исходит из вашего локального хоста, а не из внешнего источника, и, по моему опыту, это обычно принимается как "установленное соединение" большинством брандмауэров, поскольку большинство брандмауэров настроены принимать любые исходящие соединения.

Я мог бы увидеть это, если бы ваш брандмауэр был настроен на блокировку процессов, а не только соединений. В этом случае в белый список необходимо внести Node.

Требуется дополнительная информация, чтобы действительно понять, почему это с вами происходит. Хотя, вероятно, было бы эффективнее открыть новый билет. Это было связано с fsevents в MacOS, вызывающим проблемы, и это было решено, поэтому сейчас закрыто. Все, что не связано с fsevents действительно должно иметь свою проблему, чтобы привлечь внимание, которого оно заслуживает.

Для записи, это также может произойти, если ваш сервер GraphQL работает в режиме отладки и остановлен в точке останова.

Для записи: это начало происходить со мной, когда я добавил gatsby-source-s3-image и корзина s3 достигла более 100 изображений. Он просматривает все 145 изображений на этапе source and transform nodes и затем зависает там навсегда. Это все еще происходит, я пробовал исправления выше. К счастью, он работает после 5-6 попыток, поэтому я не заблокирован.

У меня сработало странное изменение размера окна терминала

Мне кажется, что ограничение одновременных загрузок, как описано здесь , помогает.

Я добавил следующую строку в свой файл .env. По умолчанию 200.
GATSBY_CONCURRENT_DOWNLOAD=50

Не уверен, что это решит вашу проблему, но, возможно, это кому-то поможет :)

@ rishabhaggarwal2 Есть похожая проблема, которая, похоже, может быть тем, с чем вы столкнулись, когда она зависает при извлечении данных из онлайн-источника. Можете попробовать использовать GATSBY_CONCURRENT_DOWNLOAD=10 gatsby develop ?

Спасибо, это исправило для меня. Поскольку я загружал тонны контента со стороннего веб-сайта, он постоянно зависал при загрузке контента. (97% - так близко еще пока)