[gatsby-source-contentful]: Report illegal content model names

[daugsbi]

Description

After upgrading my project to the latest gatsby and gatsby-source-contentful version, I was getting an error during development and building the project: TypeError: typeComposer.addInterface is not a function.

I was able to determine the problem relies in gatsby-source-contentful. After a lot of debugging I've realised that a naming collision between my content model and the Interfaces from gatsby-source-contentful triggered the error.

I didn't expect that the naming of content models is limited. Additionally the error message didn't help.

Steps to reproduce

Create a workspace in Contentful and name a model Reference. This could also work with Entity.

Expected result

An error message should warn the user.
i.e. Incompatible ContentModel detected. Please rename Reference/Entity to something else.

Actual result

TypeError: typeComposer.addInterface is not a function.

Environment

System:
OS: Linux 5.4 Ubuntu 20.04.2 LTS (Focal Fossa)
CPU: (24) x64 AMD Ryzen 9 3900X 12-Core Processor
Shell: 5.0.17 - /bin/bash
Binaries:
Node: 14.15.0 - /usr/local/bin/node
Yarn: 1.22.4 - /usr/bin/yarn
npm: 6.14.8 - /usr/local/bin/npm
Languages:
Python: 2.7.18 - /usr/bin/python
Browsers:
Chrome: 88.0.4324.150
Firefox: 85.0.1
npmPackages:
gatsby: ^2.32.3 => 2.32.3
gatsby-background-image: ^1.4.1 => 1.4.1
gatsby-image: ^2.11.0 => 2.11.0
gatsby-plugin-feed: ^2.13.0 => 2.13.0
gatsby-plugin-image: ^0.7.1 => 0.7.1
gatsby-plugin-mailgo: ^0.11.3 => 0.11.3
gatsby-plugin-manifest: ^2.12.0 => 2.12.0
gatsby-plugin-offline: ^3.10.0 => 3.10.0
gatsby-plugin-plausible: ^0.0.7 => 0.0.7
gatsby-plugin-react-helmet: ^3.10.0 => 3.10.0
gatsby-plugin-remove-trailing-slashes: ^2.10.0 => 2.10.0
gatsby-plugin-robots-txt: ^1.5.5 => 1.5.5
gatsby-plugin-sharp: ^2.14.1 => 2.14.1
gatsby-plugin-sitemap: ^2.12.0 => 2.12.0
gatsby-plugin-tslint: ^0.0.2 => 0.0.2
gatsby-plugin-typescript: ^2.12.0 => 2.12.0
gatsby-plugin-webpack-bundle-analyser-v2: ^1.1.20 => 1.1.20
gatsby-remark-attr: ^0.1.0 => 0.1.0
gatsby-remark-autolink-headers: ^2.11.0 => 2.11.0
gatsby-remark-grid-tables: ^0.1.0 => 0.1.0
gatsby-remark-table-of-contents: ^1.0.0 => 1.0.0
gatsby-remark-vscode: ^3.2.0 => 3.2.0
gatsby-source-contentful: 4.6.1 => 4.6.1
gatsby-source-filesystem: ^2.11.0 => 2.11.0
gatsby-theme-material-ui: ^1.0.9 => 1.0.13
gatsby-transformer-remark: ^2.16.0 => 2.16.0
gatsby-transformer-sharp: ^2.12.0 => 2.12.0

[ascorbic]

@axe312ger this sounds like a relatively simple DX fix. What do you reckon?

[axe312ger]

@ascorbic Yes should be. I wonder If we should try/catch it or have a list of illegal names. We have it for field names already:

https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-contentful/src/gatsby-node.js#L18

[axe312ger]

if we go for the list, any idea which names would be blocked by Gatsby?

[vladar]

I think only those fields:

gatsby/packages/gatsby/src/schema/types/node-interface.ts

Line 11 in fe737d0

export const NodeInterfaceFields = [`id`, `parent`, `children`, `internal`]

[axe312ger]

@vladar but these do not overlap with Entity & Reference 🤔

[vladar]

Oh right, I've misunderstood the question at first. Now I see that the problem is not with fields but with type names. The plugin defines interface types here:

gatsby/packages/gatsby-source-contentful/src/gatsby-node.js

Lines 327 to 340 in 3ffc210

	createTypes(`
	interface ContentfulEntry @nodeInterface {
	contentful_id: String!
	id: ID!
	node_locale: String!
	}
	`)
	createTypes(`
	interface ContentfulReference {
	contentful_id: String!
	id: ID!
	}
	`)

But if someone uses Entry or Reference in Contentful model names - they cause conflicts with those internal plugin types (because in the contentful plugin those model names are also transformed to ContentfulEntry and ContentfulReference).

So this is a conflict on a plugin level - Gatsby doesn't restrict type names (as long as they are prefixed with Contentful). So I think for list-based exceptions you can just go with Reference and Entry (and whatever other internal type names the plugin has). Alternatively, you can rename plugin interface types to something else, e.g. InternalContentfulReference (but that will be a breaking change).