Gatsby: ValidationError: child "internal" fails because [child "owner" fails because ["owner" is required]]

Created on 16 Jul 2018  ·  13Comments  ·  Source: gatsbyjs/gatsby

Description

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
if name isn’t set, the folder name for the plugin is used

This appears to not be working. I followed the {} advice to get going quickly.

Steps to reproduce

Write a local plugin that attempts to add source nodes with an empty package.json file.

Expected result

Gatsby should set the owner to the folder name of the plugin.

Actual result

The new node didn't pass validation
ValidationError: child "internal" fails because [child "owner" fails because ["owner" is required]]

Environment

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

File contents (if changed)

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

help wanted stale? bug

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

All 13 comments

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

mikestopcontinues picture mikestopcontinues  ·  3Comments

Oppenheimer1 picture Oppenheimer1  ·  3Comments

magicly picture magicly  ·  3Comments

signalwerk picture signalwerk  ·  3Comments

kalinchernev picture kalinchernev  ·  3Comments