Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[gatsby-source-contentful] - Gatsby errors trying to create two Union types with the same name #3544

Closed
JasonStoltz opened this issue Jan 16, 2018 · 10 comments

Comments

@JasonStoltz
Copy link

Description

I have two Content Types in Contentful. They both have a media field that can be a Link to one of two types, BackgroundVideo or ImageWithAltText.

mediaModuleFull (Entity)
  media: (Link: BackgroundVideo|ImageWithAltText)

mediaModuleHalf (Entity)
  media: (Link: BackgroundVideo|ImageWithAltText)

When running gatsby develop, the above setup errors out with the following error message:

Error: Schema must contain unique named types but contains multiple types named "Union_media___NODE_ContentfulBackgroundVideo__ContentfulImageWithAltText"

I believe the error stems from this: https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/schema/infer-graphql-type.js#L318. There is no check here to see if this Union type already exists, it appears that it always attempts to create a new Union.

Environment

Gatsby version: 1.9.149
Node.js version: v8.9.4
Operating System: macOS 10.12.1

Actual result

An error is throw

Expected behavior

The Union already exists, so it is reused for this field.

Steps to reproduce

  1. Create 4 types in Contentful, mediaModuleFull, mediaModuleHalf, backgroundVideo, imageWithAltText`
  2. Add a multi-reference field both mediaModuleHalf and mediaModuleFull, named media
  3. Create 2 instances of mediaModuleFull, one with a backgroundVideo linked in media, and 1 with a imageWithAltText linked in media.
  4. Do the same for mediaModuleFull.
  5. Make sure all of this is fully published.
  6. Fire up a Gatsby project with gatsby develop, which is connected to this Contentful space via that gatsby-contentful-source plugin.

...

@JasonStoltz
Copy link
Author

@Khaledgarbaya, FYI. Not sure if you've seen this.

@Khaledgarbaya
Copy link
Contributor

Hey @JasonStoltz,
there seems to be a problem, in this case, I haven't had time to check it out but as a workaround for now if you can maybe change the field from a single reference to multireference filed (array of refs).

I will try to check it out soon, I've been crazy busy lately :(

Best,
Khaled

@jtschulz
Copy link
Contributor

Running into this too. I don't think it's to do with the multi-type single reference fields bug. This seems to occur when two different content types have fields that create the same union. I'm getting this error on a one-to-many reference, it's just that three different kinds of pages have the same type of one-to-many reference.

@fk fk added the API/Plugins label Jan 29, 2018
@michaek
Copy link
Contributor

michaek commented Apr 10, 2018

I'm not that versed in Gatsby's internals, but I tried working with this a bit. Just reusing a single union type seemed to cause problems because descendants of the type could have duplicate names, so it seemed worth just having an increment value appended to the union type name. For the example in the issue, that would become Union_media___NODE_ContentfulBackgroundVideo__ContentfulImageWithAltText__0, etc.

I'm not sure if that has unintended consequences, but since the union type is internal from a Gatsby user's perspective, I was hoping it wouldn't cause problems to just change the name.

@pieh
Copy link
Contributor

pieh commented Apr 10, 2018

@michaek if you want to fix this I would try wrapping name of created union type ( https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/schema/infer-graphql-type.js#L251 ) with createTypeName call which will add _2 (and so on) suffixes if type name was already used

@michaek
Copy link
Contributor

michaek commented Apr 10, 2018

@pieh That does the trick. Perhaps if it was called createUniqueTypeName I would have realized what it was and used the function without experimenting with some hand-rolled suffixing. :)

@michaek
Copy link
Contributor

michaek commented Apr 10, 2018

@pieh Is there some published process for how to consume a hotfixed lerna package? Since this issue is a showstopper for builds, I'd really like to avoid waiting for a merge and release of #4925. The elaborate build and release process Gatsby uses makes it kind of tricky to just plug in a hotfixed dependency via npm, which is what I would expect to be able to do.

@pieh
Copy link
Contributor

pieh commented Apr 10, 2018

I didn't do anything like that but maybe this blog post will be helpful - https://medium.com/@denis.zhbankov/maintaining-a-fork-of-create-react-app-as-an-alternative-to-ejecting-c555e8eb2b63#1568 and then you would probably need to some tricks in package json to alias your package to gatsby so gatsby-cli and other stuff that directly require gatsby package would work correctly.

another temporary solution would be npm pack, host tarball somewhere and install gatsby via that tarball

@michaek
Copy link
Contributor

michaek commented Apr 10, 2018

The npm pack approach is the direction I was thinking, but I haven't yet got npm to consume the tarball correctly, as it's been excluding the dist/ directory, without which there's no gatsby.

The convenience of being able to just

  "dependencies": {
    "gatsby": "michaek/gatsby",

until one's PR is accepted is pretty appealing. I understand the appeal of a monorepo and transpiled source from an author's perspective, but it can make things kind of cumbersome for a consumer. :)

@michaek
Copy link
Contributor

michaek commented Apr 10, 2018

For what it's worth, I was just missing the file: protocol, as in:

  "dependencies": {
    "gatsby": "file:./gatsby-v1.9.247.tgz",

Where the tarball was generated with yarn run build && yarn pack from packages/gatsby/. You could also use npm run build && npm pack.

Sorry to everyone for this off-topic series of messages!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants