chore: check finalWatchFileSystem.watcher nullability #172
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
No problem, lets merge it. Published in version |
1 task
serhalp
added a commit
to gatsbyjs/gatsby
that referenced
this pull request
Aug 14, 2025
to get this bug fix: sysgears/webpack-virtual-modules#172 causing this, unclear when: ``` TypeError: Cannot read properties of null (reading 'fileWatchers') ```
serhalp
added a commit
to gatsbyjs/gatsby
that referenced
this pull request
Aug 15, 2025
to get this bug fix: sysgears/webpack-virtual-modules#172 causing this, unclear when: ``` TypeError: Cannot read properties of null (reading 'fileWatchers') ```
serhalp
added a commit
to gatsbyjs/gatsby
that referenced
this pull request
Aug 19, 2025
* test(gatsby-cli): tolerate varying stack traces * test: import mocked module the same way it's used This mismatch stopped working after node 18. * test: use more specific snapshot for res headers Some of the connection header defaults depend on the node.js major version wip this is a fix for the headers one * test: skip unstable GC tests on node 20+ * test: adjust assertion to work on node 22 locally See inline comment * test: fix sharp build error in lmdb-regeneration fixture The `lmdb-regeneration` integration test fixture had an `.npmrc` file forcing all packages to be built from source, which caused sharp to fail compilation in Node 20+ CircleCI images (Ubuntu Noble) due to... who knows what, honestly. Since this fixture specifically needs lmdb built from source but not sharp (it's testing something specific to this), this replaces the global `.npmrc` `build-from-source` flag with a targeted `postinstall` script that only rebuilds lmdb from source, allowing sharp to use prebuilt binaries. This resolves the "cannot find -l:libvips-cpp.so.42" linker errors that were blocking integration tests on Node 20+ while preserving the fixture's intended lmdb compilation testing. AFAICT this was... basically the only solution. Whew * fix(gatsby): bump `webpack-virtual-modules` to get this bug fix: sysgears/webpack-virtual-modules#172 causing this, unclear when: ``` TypeError: Cannot read properties of null (reading 'fileWatchers') ``` * ci: test against Node 18, 20, 22 - run unit tests against all three - run integration tests against earliest and latest - make sure to separate npm cache by node version * ci: test against node 22.13 to avoid bug for now
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this PR, I have added a check for the nullability of
finalWatchFileSystem.watcherBackground
This library is used by the development server that starts up during Gatsby development.
Gatsby features a function named DEV_SSR, which makes it easier to detect SSR errors during development. However, when this feature is enabled in our environment and an actual SSR error occurs, the development server itself shuts down due to the following error in this library:
This prevents us from verifying the content of the SSR error, defeating the purpose of the DEV_SSR feature. While I have not fully investigated why
finalWatchFileSystem.watcherbecomes null, I believe that the modification proposed in this PR will not have any adverse effects. I would appreciate it if you could consider merging this change.