Clean up peer dependencies in first-party plugins

[aaronadamsCA]

Preliminary Checks

• This issue is not a duplicate. Before opening a new issue, please search existing issues: https://github.com/gatsbyjs/gatsby/issues
• 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

Yarn 3 gives some warnings on first-party plugins due to inaccurate peer dependencies. Some examples:

[gatsby-site] doesn't provide @babel/core, requested by gatsby-plugin-image
[gatsby-site] doesn't provide webpack, requested by gatsby-plugin-gatsby-cloud
[gatsby-site] doesn't provide gatsby-source-filesystem, requested by gatsby-plugin-image
gatsby-source-shopify@npm:6.6.0 doesn't provide gatsby, requested by gatsby-plugin-utils
gatsby-source-shopify@npm:6.6.0 doesn't provide gatsby, requested by gatsby-source-filesystem

For the first two, those shouldn't be peer deps of those packages; the third one should be marked optional with peerDependenciesMeta, since you only need it in certain use case; for the last two, the plugin should have Gatsby as a peer dependency.

I'd like to improve some of these, but I figured it'd be best to check first if (a) anyone else is looking at this issue and (b) it's okay to do it all in a single PR.

[pieh]

Hi @aaronadamsCA, we definitely would welcome improvement to (peer)dependencies situation.

One thing that we are missing (other than fixing dep problems) is some automated tests to ensure we don't regress in this area in future.

I remember trying out https://github.com/import-js/eslint-plugin-import/blob/main/docs/rules/no-extraneous-dependencies.md at some point in past, but there was some problems with it back then (don't remember if problem was with eslint rule in general or just something about that rule that didn't work for us). But this would only solve part of the issue you described. For example 1-2 seems like plugins actually want to use things that gatsby core provide, but you can't really do it like that (instead gatsby should re-export pieces like that, and then plugin can have peerDep on gatsby and import webpack/babel from it or alternatively plugins should use https://nodejs.org/api/module.html#modulecreaterequirefilename )

[aaronadamsCA]

Makes sense. Some thoughts:

• We use import/no-extraneous-dependencies in our monorepo and it's solid; granted, our deps are 1% as complex as yours, since we don't ship public packages.
  • For specific use cases, like making sure Storybook files don't import directly from peer dependencies, we use targeted overrides patterns (e.g. files: ["!packages/{package-one,package-two}/**"]).
• I agree re-exports could work, though another (IMO potentially better) option is to move these to true peer dependencies for Gatsby 5.
  • I think Gatsby generally recommends the use of a starter, so I don't think this would necessarily harm beginners.
  • The manual install command in the docs would certainly grow, but that now seems to be the direction the ecosystem is going; in the last year many of our larger deps have moved their own major deps from transitive to peer, and it's invariably made life better, not worse. In our repo, Webpack, TypeScript, ESLint, and Babel are all used by more than just Gatsby, and having more direct control of these dependencies would be great.
• Maybe a check that installs every package with Yarn 3 could be enough to validate, since it reliably warns on any dependency issues it finds. Warnings should be enough for now, since they're generally worth resolving, but not necessarily worth blocking a merge or release.

Locally, I've used the following packageExtensions in .yarnrc.yml:

packageExtensions:
  gatsby-plugin-image@*:
    peerDependenciesMeta:
      gatsby-plugin-sharp:
        optional: true
      gatsby-source-filesystem:
        optional: true
  gatsby-source-shopify@^6:
    peerDependencies:
      gatsby: ^4

I'm pretty sure these would be harmless PRs, so I'll try to file them soon.

[github-actions]

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! 💪💜

[aaronadamsCA]

Not stale, PR filed!

[github-actions]

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]

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! 💪💜