Queries are extracted for all themes/plugins in package.json, not only the ones configurated.

[laurenskling]

Preliminary Checks

• [X] This issue is not a duplicate. Before opening a new issue, please search existing issues: https://github.com/gatsbyjs/gatsby/issues
• [X] This issue is not a question, feature request, RFC, or anything other than a bug report directly related to Gatsby. Please post those things in GitHub Discussions: https://github.com/gatsbyjs/gatsby/discussions

Description

Context: I am working with themes from a yarn workspaces monorepo.

As soon as I add a package to a package.json somewhere in my site/theme stack, queries are extracted from that package/workspace. I would assume only plugins/themes that are actually loaded via the gatsby-config.js module.exports = ({ plugins: [...] }) would have their queries extract. Not only is it inefficient to extract queries that aren't being used, it also limits me from creating multiple themes running different versions of certain queries (especially creating multiple versions of fragments).

Reproduction Link

https://github.com/laurenskling/gatsby-extracted-query-in-themes-duplicate

Steps to Reproduce

1. start using worspaces (with yarn)
2. start a gatsby site rocking some fragments
3. create a theme that also exports that fragment name
4. install that package in your gatsby site.
5. wait for the boom. Found two different GraphQL fragments with identical name "X". Fragment names must be unique

Expected Result

I would expect packages that i do not load in gatsby-config would not actually be used.

Actual Result

Gatsby is extracting all queries it can find, also in not-loaded themes/plugins

Environment

System:
    OS: macOS 12.6
    CPU: (8) x64 Apple M2
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 14.20.0 - /var/folders/50/3fndm5d13gs_kr96nwxpxd9c0000gn/T/yarn--1667131075616-0.15462311276364815/node
    Yarn: 1.22.19 - /var/folders/50/3fndm5d13gs_kr96nwxpxd9c0000gn/T/yarn--1667131075616-0.15462311276364815/yarn
    npm: 6.14.17 - /usr/local/bin/npm
  Languages:
    Python: 3.10.8 - /usr/local/bin/python
  Browsers:
    Chrome: 106.0.5249.119
    Safari: 16.0

Config Flags

PRESERVE_FILE_DOWNLOAD_CACHE: true, FAST_DEV: true, DEV_SSR: false,

[pieh]

The problem with extracting queries (and fragments) just from plugins configured in gatsby-config is that this will break extraction from packages that are not really plugins or themes and hence wouldn't be added to config, just some reusable utilities or hooks. Kind of like gatsby specific useSiteTitle hook that might use useStaticQuery to grab site.siteMetadata.title. So it's "pick your poison" situation - implementing your suggestion means breaking something else we currently support.

There is a way to probably solve this by moving extraction to be part of webpack build instead of separate step, as then we could follow imports of things that are actually used in given build, but that's a bigger change that would take quite a bit of effort, could have unforseen regressions for not that much benefit.

As a workaround - for query names I suggest to drop the names completely, for the fragment names - if possible add a postfixes so fragment names are unique and the consumer code adjustment (if queries using fragments are outside of a plugin that define a fragment) can be semi-automated with search&replace / sed

[laurenskling]

Many thanks for your swift reply @pieh .

That sounds like a dilemma, yes. I would understand you wouldn't want to take a bunch of effort to get the small gain of only using queries actually used. Although that would really be helpful in my case. Running from a monorepo, there are many many unused queries (specially fragments) all around.

Your workaround suggestion wouldn't work for me. Let me explain:

• I have a pages theme, that runs a template with a pageQuery using some fragments. To fetch page data. I'd like to add a fragment for fetching Form data when the forms theme is included and this site is using forms. Like so:

{ 
  strapiPage {
     id
     ...PageFragment
     ...FormOnPageFragment
  }
}

I'd like to export the FormOnPageFragment in gatsby-theme-forms where I also do a createTypes making sure all the fields are available in the schema. When another site is not using forms. I don't need the types, I don't need to query it. But I must set FormOnPageFragment somewhere to make sure the strapiPage query doesn't crash. Just making a fallback fragment only fetching id will do, but if I do so, I will have duplicate fragment names.

This doesn't only apply to additional fetching like this; also things like making query adjustment for different sites: like shadow the fragment to request different image sizes. I would create a shadow file in my site overriding the theme fragment. This is impossible right now. It would be insanely powerful if I could do that.

[github-actions[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 20 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[laurenskling]

Still hoping we can find a solution for me 👻

[github-actions[bot]]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 20 days since the last update here. If we missed this issue or if you want to keep it open, please reply here. As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[github-actions[bot]]

Hey again!

It’s been 60 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it. Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to comment on this issue or create a new one if you need anything else. As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community! 💪💜