Gatsby fails resolving node_modules in monorepo #11780
Comments
|
Actually this may be my environment. When running Does anyone have any insight to why this may be happening? |
|
I've exhausted myself trying to figure this one out. I don't think this has to deal directly with Gatsby or its package, but I do think it's odd that I'm having issues with only a handful of plugins. The bulk of the issue has been resolve by adding The plugins I am having issues with:
I'm going to leave this issue open for now in case anyone has any insight |
|
This is very weird, because folks working on some features use yarn workspaces quite often and didn't seem to hit problems with it. It seems like workspaces isn't correctly installing deps and setting symlinks? Maybe issue lies with |
|
I agree this is very odd, and I thought I set everything up to the spec. I'm removing lerna from the equation to see if the issue persists. The dependencies weren't being installed at all. They are added to the root's lockfile and the package's package.json file, but the package was nowhere to be found in any I'm going to play around with this some more after learning about the |
|
Ok, I ended up getting this working. Using @jedrichards snippet from his monorepo example: "workspaces": {
"nohoist": [
"gatsby"
]
}I didn't know the The trick was to use a globbing pattern in the "workspaces": {
"nohoist": [
"**/gatsby",
"gatsby/**",
"**/gatsby-*",
"gatsby-*/**",
"**/*-gatsby",
"*-gatsby/**"
]
}I feel like this definitely needs to be mentioned in the Gatsby docs. |
|
@josefaidt I'm still kind of unsure why there's an issue there. That nohoist looks pretty gnarly. I think in this case it probably makes sense to investigate what exactly breaks with that particular directory structure rather than documenting this scenario--which seems a bit niche-y and may just lead to confusion. For instance, I structured a recent repository I created as a monorepo with Yarn workspaces, and I didn't really have any issues whatsoever with resolving Gatsby. https://github.com/DSchau/gatsby-drupal-workshop Is there an easily discernible difference or something we can fix here? If at all possible, sharing a repository, rather than documenting its structure, would be super helpful! |
|
At first I thought this was an issue with Gatsby and how it resolves modules as I did not have an issue with a pure React build. That is why I raised the issue, however I now know that it most likely is not a Gatsby-specific issue, but rather a "quirk", if you will, to using it this way. I took a look at your repo and I'm honestly surprised you haven't had any issues without any hoisting. But what was weird was that originally my issue was affecting specific gatsby packages. I'm still not quite sure what the root cause of the issue is, and unfortunately I cannot share the original repo but I made a proof of concept: https://github.com/josefaidt/monorepo-gatsby Considering this issue is resolved and in the end not entirely relevant to Gatsby I am closing it. |
|
@josefaidt There were a few tiny errors in your proof of concept above. Check it out: https://github.com/josefaidt/monorepo-gatsby/pull/1 |
|
@josefaidt did this proof of concept work? I am trying to get a lerna monorepo set up and am running into about a days worth of issues seemingly related to staticquery's not being picked up if they are not in main src folder. In demo i see you had all your quries in site folder but was wondering if you went further with this? |
|
@carllippert yes, however I use yarn without lerna now. My personal site uses a monorepo with a theme, demo site, and app site. In app/content/pages/resume.mdx you can see I'm using a page query outside of the source folder |
|
@josefaidt did removing lerna aid in this? I would have to do a lot of digging but i think when you use the page-creator plugin it then can pickup pageQueries but yet basically just scans src folder for StaticQuery and useStaticQueryHooks thus killing any components say in a shared ui package. I use page creator to generate pages in a dif package and that seemingly works its just the underlying components on the page. Anyways thanks for giving me something to look over for inspiration. 👍 |
|
I had a similar issue in a monorepo with a gatsby project in a seperate package: storybook with a custom webpack config using Using the fix described by @josefaidt gatsby is able to resolve file-loader again (when importing local fonts in my case). I don't know if this issue lies with yarn workspaces or with the way gatsby dependencies are listed/required, but hopefully this sheds some more light on it for somebody. |
Description
When using a monorepo with lerna and Yarn workspaces I am attempting to set up multiple, different Gatsby sites under a
./startersfolder (from scratch or using the cli), and they will all use a shared component library under./packagesfolder. The issue seems to be affecting Gatsby itself and how it resolves packages.I am able to use my existing React stack setup in the same monorepo without issue. Gatsby site fails with and without
reactandreact-domin rootpackage.jsonSKIP TO SOLUTION for using base Gatsby in a monorepo
Steps to reproduce
mkdir starters/gatsbycd starters/gatsbyyarn -y inityarn workspace gatsby add gatsby gatsby-image gatsby-plugin-manifest gatsby-plugin-offline gatsby-plugin-react-helmet gatsby-plugin-sharp gatsby-plugin-styled-components gatsby-source-filesystem gatsby-transformer-sharp prop-types styled-components react react-dom react-helmetstartscript. Everything runs great on the first run with 0 files added (nogatsby-*files, nosrcdirectory).gatsby-config.jsandsrcdirectory from default starterdevelopscript. Fails.cd startersgatsby new new-sitecd .. && yarn workspace gatsby run develop, site runs finepackages/lerna clean && lerna bootstrapyarn workspace gatsby run developand it fails finding the modulegatsby/graphqlyarn workspace gatsby add gatsby-transformer-jsongatsby-config.jsfile as necessaryyarn workspace gatsby run developScripts
{ "scripts": { "start": "yarn develop", "develop": "gatsby develop --verbose", "build": "gatsby build" } }Expected result
Running
yarn workspace gatsby run developruns the site as intended. Sometimes this actually works after freshly installing new gatsby site to mystartersfolder. I can quit, bootstrap my dependencies and rerun the same command to expect the failure describe below (without gatsby as a dependency in the root package.json).Actual result
Running
yarn workspace gatsby run developGatsby fails on resolving only one of three packages:gatsby/graphql(most common)gatsby-plugin-react-helmetgatsby-source-filesystemgatsby-transformer-jsonStack Traces
Stack Trace for `gatsby-plugin-react-helmet`
Stack Trace for `gatsby/graphl`
Stack trace for `gatsby-transformer-json`
Environment
SOLUTION (well, was)
After much testing and trial/error, I've found the monorepo needs gatsby declared in the root
package.jsonlerna clean && lerna bootstrapyarn workspace gatsby run developI typed this up and continued working thinking it may be my environment, however after adding another plugin the site began to break and show similar symptoms to those described above.
The text was updated successfully, but these errors were encountered: