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-transform-json silently fails when JSON has same key with different value types #2404

Closed
danoc opened this issue Oct 9, 2017 · 4 comments

Comments

@danoc
Copy link
Contributor

danoc commented Oct 9, 2017

Imagine I have two files, number.json and string.json within the same directory. The only different is the type of the value.

{
    "name": "Number",
    "value": 123
}
{
    "name": "String",
    "value": "123"
}

Using gatsby-source-filesystem and gatsby-transformer-json, only name becomes available within GraphQL. Because the value types are different, the data is not added to GraphQL and is not queryable.

Changing both to use the same data type would make it work.


Is this a known issue or desired behavior? I can produce a smaller test case, if needed.

FWIW, I don't think this is an issue with either of those two plugins because createNode(jsonNode) within gatsby-transformer-json receives the correct object.

@KyleAMathews
Copy link
Contributor

Yes, Gatsby ignores fields with inconsistent types.

So beyond making sure all the fields are the same type, you could also put these files in different directories so that their type name is different. JSON files with single objects in them get a type name derived from the directory they're in.

@danoc
Copy link
Contributor Author

danoc commented Oct 9, 2017

Great, thanks @KyleAMathews. I figured this was the case. I'm going to reshuffle my data around so this is not an issue.

It would be great if a warning is outputted when this happens. (That said, I have no idea how complicated that is to implement.)

Feel free to close this if you'd like!

@KyleAMathews
Copy link
Contributor

A warning would be great to output actually! That'd be a lot less confusing/surprising than what we do now, silently dropping data.

I'll keep this open and update the title to reflect the work to be done.

/cc @jquense

@KyleAMathews
Copy link
Contributor

Actually, I'm make another issue :-)

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

2 participants