fix(nextjs): Fix resolution of request async storage module #9259
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.
Fixes #9120
Adresses #9092 (comment)
Previously we failed to properly locate Next.js'
request-async-storage
module in monorepo setups because we were limiting our search to a subset of paths inwebpackConfig.resolve.modules
.Example:
webpackConfig.resolve.modules
contained["<absolute_path_to_monorepo>/packages/<project_with_next_js>/node_modules", "<absolute_path_to_monorepo>/packages/<project_with_next_js>"]
request-async-storage
is located at/<absolute_path_to_monorepo>/node_modules/next/dist/client/components/request-async-storage.external.js
request-async-storage
was not inwebpackConfig.resolve.modules
or any subpaths, we marked it as not resolved.New solution: We look upwards from the webpack resolvable paths in the folder tree using the default node resolving algorithm to look for the nearest
next
installation. Once found, we try to look for the therequest-async-storage
modules inside that installation.Additional considerations
I don't know whether it is enough to check the webpack resolvable locations. Even worse, I don't know whether looking upwards from the webpack resolvable locations is problematic because it might not resemble what webpack is doing.
Adding a dependency
We are using the
resolve
package because it let's us look upwards from a certain location without using stuff likerequire.resolve
which might trip up webpack.