Writing a local plugin I started to get the following ValidationError when trying to add a new node source.
The new node didn't pass validation
ValidationError: child "internal" fails because [child "owner" fails because ["owner" is required]]
Being new to Gatsby I thought that perhaps I needed to set this value. Doing so produced:
The node internal.owner field is set automatically by Gatsby and not by plugin
I finally tracked this down to my package.json file not having a name. According to the docs:
this can be an empty object ({}) for local plugins
ifnameisn’t set, the folder name for the plugin is used
This appears to not be working. I followed the {} advice to get going quickly.
Write a local plugin that attempts to add source nodes with an empty package.json file.
Gatsby should set the owner to the folder name of the plugin.
The new node didn't pass validation
ValidationError: child "internal" fails because [child "owner" fails because ["owner" is required]]
System:
OS: macOS Sierra 10.12.6
CPU: x64 Intel(R) Core(TM) i7-4980HQ CPU @ 2.80GHz
Shell: 3.2.57 - /bin/bash
Binaries:
Node: 9.11.2 - ~/.nvm/versions/node/v9.11.2/bin/node
Yarn: 1.5.1 - /usr/local/bin/yarn
npm: 5.6.0 - ~/.nvm/versions/node/v9.11.2/bin/npm
Browsers:
Chrome: 67.0.3396.99
Firefox: 61.0
Safari: 11.1.1
npmPackages:
gatsby: 1.9.273 => 1.9.273
gatsby-link: ^1.6.40 => 1.6.45
gatsby-node-helpers: ^0.3.0 => 0.3.0
gatsby-plugin-react-helmet: ^2.0.10 => 2.0.11
gatsby-remark-autolink-headers: ^1.4.19 => 1.4.19
gatsby-remark-images: ^1.5.67 => 1.5.67
gatsby-remark-prismjs: ^2.0.4 => 2.0.4
gatsby-source-filesystem: ^1.5.39 => 1.5.39
gatsby-transformer-remark: ^1.7.44 => 1.7.44
gatsby-transformer-yaml: ^1.5.18 => 1.5.18
npmGlobalPackages:
gatsby-cli: 1.1.58
gatsby-config.js: N/A
package.json:
{}
gatsby-node.js (simplified):
exports.sourceNodes = ({ boundActionCreators }, options = {}) => {
const { createNode } = boundActionCreators
const pages = []
const node = {
id: 'Docs_Menu',
children: [],
parent: 'MENU',
internal: {
type: 'Menu',
contentDigest: JSON.stringify(pages)
},
pages
}
createNode(node)
}
gatsby-browser.js: N/A
gatsby-ssr.js: N/A
We are loading plugins here https://github.com/gatsbyjs/gatsby/blob/49a63571fd1f369e1b2ea4bc0f1eb508d4465810/packages/gatsby/src/bootstrap/load-plugins/load.js#L36-L82
And it looks like it should pick directory name as name of plugin for local plugins - can You share Your repository?
Here is the repo. I changed the package.json to not have a name property to show it broken.
https://github.com/graphql-dotnet/graphql-dotnet/tree/950c5f2c96bbb33b9379bf89276948f290899b76/docs2
What happens if you do this change here https://github.com/graphql-dotnet/graphql-dotnet/blob/950c5f2c96bbb33b9379bf89276948f290899b76/docs2/gatsby-config.js#L16:
- resolve: path.resolve('./plugins/docs'),
+ resolve: 'docs',
?
because You are giving full absolute path so it wouldn't be treated as local plugin
👍 That does fix it!
Two things that I think could have helped me figure this out faster:
1) Have an example local plugin registration in gatsby-config.js in the docs (to show that I shouldn't be using an absolute path for a local plugin). The There is no auto-detection of local plugins text is what probably led me to believe that I did. It doesn't auto-load them, but it does treat the plugins folder as a place to look.
2) A better validation exception, pointing me to the missing name in the package.json.
I wonder if we should fallback to directory name for plugins that aren't considered as local plugins right now. Instead of creating more detailed docs about restrictions, let's try to get rid of those restrictions
Yeah, if a non-local plugin doesn't have a name, let's just hard fail.
Old issues will be closed after 30 days of inactivity. This issue has been quiet for 20 days and is being marked as stale. Reply here or add the label "not stale" to keep this issue open!
Bump
This issue is being closed due to inactivity. Is this a mistake? Please re-open this issue or create a new issue.
@joemcbride is there a TODO still here?
@KyleAMathews yes, if this was never done:
if a non-local plugin doesn't have a name, let's just hard fail
@joemcbride oh thanks! Could you make a new issue for this?
Preferably with a simple reproduction
Most helpful comment
I wonder if we should fallback to directory name for plugins that aren't considered as local plugins right now. Instead of creating more detailed docs about restrictions, let's try to get rid of those restrictions