Gatsby: Can't use React components contained in a local plugin

Created on 5 Apr 2020  ·  10Comments  ·  Source: gatsbyjs/gatsby

Description

While local plugins totally work for accessing Gatsby hooks, I can't seem to make them work for just loading a React component.

Steps to reproduce

  1. Generated project from gatsby new gatsby-component-plugin-bug
  2. Created plugins/gatsby-local-plugin and added the required files (index.js, gatsby-config.js) and ran npm install
  3. Moved the implementation of header.js from the src directory to inside the new plugin
  4. Adjusted paths
  5. Added the local plugin

I created this as a Git repo with the first commit being the starting point from gatsby new and the second commit being all of the changes I made: https://github.com/wirehead/gatsby-component-plugin-bug

Expected result

I expected the header.js component from the gatsby-local-plugin plugin to load.

Actual result

> gatsby develop

success open and validate gatsby-configs - 0.052s
success load plugins - 2.393s
successIonPreInit - 0.005s
successainitialize cache - 0.008s
success copy gatsby files - 0.191s
success onPreBootstrap - 0.024s
success createSchemaCustomization - 0.011s
success source and transform nodes - 0.098s
success building schema - 0.345s
successecreatePages - 0.002s
success createPagesStatefully - 0.096s
success onPreExtractQueries - 0.002s
success update schema - 0.029s
success extract queries from components - 0.305s
success write out requires - 0.047s
success write out redirect data - 0.004s
success Build manifest and related icons - 0.123s
success onPostBootstrap - 0.130s
⠀
info bootstrap finished - 8.768 s
⠀
success run queries - 0.155s - 7/7 45.02/s
success Generating image thumbnails - 4.277s - 6/6 1.40/s

 ERROR #98123  WEBPACK

Generating development JavaScript bundle failed

Can't resolve 'gatsby-local-plugin/header' in 'C:\Users\wirehead\Documents\src\gatsby-component-plugin-bug\src\component
s'

File: src\components\layout.js

faileddBuilding development bundle - 20.027s

Environment

System:
OS: Windows 10 10.0.18363
CPU: (4) x64 Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz
Binaries:
Node: 10.19.0 - C:\Program Files\nodejs\node.EXE
npm: 6.14.4 - C:\Program Files\nodejs\npm.CMD
Browsers:
Edge: 44.18362.449.0
npmPackages:
gatsby: ^2.20.12 => 2.20.12
gatsby-image: ^2.3.1 => 2.3.1
gatsby-plugin-manifest: ^2.3.3 => 2.3.3
gatsby-plugin-offline: ^3.1.2 => 3.1.2
gatsby-plugin-react-helmet: ^3.2.1 => 3.2.1
gatsby-plugin-sharp: ^2.5.3 => 2.5.3
gatsby-source-filesystem: ^2.2.2 => 2.2.2
gatsby-transformer-sharp: ^2.4.3 => 2.4.3

help wanted stale? documentation

Most helpful comment

We'd be happy to receive a PR adding this. @wirehead would you be up for it?
https://www.gatsbyjs.org/contributing/docs-contributions/

All 10 comments

@wirehead have you taken a look at gatsby browser apis and gatsby ssr api to see if they help out achieve what you want?

No, not as far as I can tell. I mean, I could just be requiring modules from a convoluted path without using one of those APIs.

However, if I were to create this plugin as a separate npm module, I could require React components, but if I do it as a local plugin, it suddenly doesn't work. Ergo, it's either a documentation bug and there needs to be a section to explain that local plugins are missing functionality as compared to a plugin implemented as a separate npm module, or it's a bug in the local plugin implementation.

Either way, this makes it really difficult to have a local plugin act as a theme with UI elements.

@wirehead doing something like import Header from 'gatsby-local-plugin/header' is going to use Webpack's module resolution, which, at its most basic, mimics node's module resolution. Since your plugin is not in node_modules, it doesn't know where to find it.

You could access it by its relative path, or you could define a Webpack alias that tells Webpack where to look when it sees gatsby-local-plugin. If you want to keep the plugin in the plugins directory for development purposes, then I would recommend a Webpack alias; you can then write all of your code as if the plugin is a production package, and when you actually deploy it, you just remove the alias.

Gatsby knows how to use the plugins directory for plugins that utilize its build API, so it will find files like gatsby-config, gatsby-node, gatsby-ssr, or gatsby-browser there. It doesn't try to intervene in your app's runtime module resolution.

Awesome, can you put that in the docs section?

Another way to use a local plugin, without having to think about aliases, is to use a monorepo structure. Then, the plugin is installed as a dependency, but that dependency just links to the local folder.

Perhaps it would make sense to put a caveat in the docs. This isn't the first time that the plugin resolution has been misinterpreted.

Yah, your reply is pretty much what the docs need to contain so the next person after me who tries this won't run up against the problem I did.

We'd be happy to receive a PR adding this. @wirehead would you be up for it?
https://www.gatsbyjs.org/contributing/docs-contributions/

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 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. You can also add the label "not stale" to keep this issue open!
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! 💪💜

Hey again!

It’s been 30 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 reopen 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! 💪💜

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mikestopcontinues picture mikestopcontinues  ·  3Comments

theduke picture theduke  ·  3Comments

dustinhorton picture dustinhorton  ·  3Comments

jimfilippou picture jimfilippou  ·  3Comments

3CordGuy picture 3CordGuy  ·  3Comments