gatsby-transformer-json crashes when .json file in directory starting with a number

[wuntusk]

Description

When running gatsby develop if you have the gatsby-transformer-json installed and anywhere in you file system you have a .json file directly inside a directory that starts with a number gatsby will crash with

UNHANDLED REJECTION Syntax Error: Unexpected Int "20"
  GraphQLError: Syntax Error: Unexpected Int "20"
  - TypeMapper.js:113 TypeMapper.createType
    [gatsby-json-crasher]/[graphql-compose]/lib/TypeMapper.js:113:43
  - ObjectTypeComposer.js:80 Function.createTemp
    [gatsby-json-crasher]/[graphql-compose]/lib/ObjectTypeComposer.js:80:28
  - ObjectTypeComposer.js:56 Function.create
    [gatsby-json-crasher]/[graphql-compose]/lib/ObjectTypeComposer.js:56:21
  - index.js:59

Steps to reproduce

add
"gatsby-transformer-json"
{
resolve: gatsby-source-filesystem,
options: {
path: ${__dirname}/src/assets,
},
},
to your gatsby-config.js

create a directory called 20m in your src/assets directory
create a file called test.json in your src/assets/20m directory with the contents

{
"test":"crash time"
}

Repro Project

Expected result

Json Data should be added to the system

Actual result

gatsby develop crashes:

UNHANDLED REJECTION Syntax Error: Unexpected Int "20"
  GraphQLError: Syntax Error: Unexpected Int "20"
  - TypeMapper.js:113 TypeMapper.createType
    [gatsby-json-crasher]/[graphql-compose]/lib/TypeMapper.js:113:43

Environment

System:
OS: Windows 10 10.0.17763
CPU: (16) x64 AMD Ryzen 7 1800X Eight-Core Processor
Binaries:
Node: 12.14.0 - C:\Program Files\nodejs\node.EXE
npm: 6.13.4 - C:\Program Files\nodejs\npm.CMD
Browsers:
Edge: 44.17763.831.0

[pieh]

Some context here. gatsby-transformer-json tries to create node with type named 20MJson. As soon as we would prefix the directory from 20m to x20m so numerics aren't first part of type it works fine.

@freiksenet @vladar Where do you think this should be addressed - should this be plugin responsibility to create node types that are valid, or would it be ok to ensure proper types in core, so plugins don't have to worry about this?

[wuntusk]

Probably the best thing here would be to A) Throw a better exception so that it's clear what's going on in core.. and then B) put it on the plugin guys to deal with this problem.. it would be solved if the plugin did prefixing rather than suffixing.. ie. Name it Json_20M rather than 20MJson. However that's a breaking change for existing sites. At a minimum a better error message from core would make life a lot easier.

[vladar]

@wuntusk Agree.

@pieh I think we should validate node.internal.type in createNode and throw if it is invalid. Silently prefixing type names in the core doesn't sound like a good idea (pretty sure it will become a source of obscure bugs).

[pieh]

@pieh I think we should validate node.internal.type in createNode and throw if it is invalid.

Can we import some typename validation utils, or would we have to re-implement them?

Silently prefixing type names in the core doesn't sound like a good idea (pretty sure it will become a source of obscure bugs).

The thing is - lot of those are autogenerated by plugins, where users might not have control over it, so only course of action would be to report that issue to plugin maintainers. But plugins also often reuse some type names from source of their data and to "fix" the issue they would need to implement some type name normalisation anyway - so that means we just shift where the normalization happen from core to plugins (which also mean normalization will need to be re-implemented in lot of plugins).

[vladar]

Can we import some typename validation utils, or would we have to re-implement them?

Validation is simple - it is pretty much defined in spec as regex /^[_a-zA-Z][_a-zA-Z0-9]*$/. But sanitizing may be a bit more difficult. There are no ready tools (afaik) to transform any string to GraphQL-compatible type name.

We use this to generate query names from file paths (which would work for type names too):

gatsby/packages/gatsby/src/query/file-parser.js

Lines 28 to 40 in acf2c35

	const generateQueryName = ({ def, hash, file }) => {
	if (!def.name || !def.name.value) {
	const slugified = slugify(file, {
	replacement: ` `,
	lower: false,
	})
	def.name = {
	value: `${_.camelCase(slugified)}${hash}`,
	kind: `Name`,
	}
	}
	return def
	}

Maybe we can extract common util from it and update a bit (i.e. obviously it won't work for this specific issue since it won't prefix numbers). Then we can use it in sanitizeNode to ensure each node key is valid (recursively). Not sure how much it will cost us in terms of performance.

[github-actions]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 30 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here. You can also add the label "not stale" to keep this issue open!
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[vladar]

@wuntusk Looks like we'd missed an option in gatsby-transform-json which can help to workaround this. You can pass typeName option in plugin config and control how fileName -> typeName mapping is handled.

See plugin docs for details.

[wuntusk]

@vladar Agreed that does allow someone to deal with invalid folder names. To verify I dropped this function in which allowed everything to build fine.

    {
      resolve: `gatsby-transformer-json`,
      options: {
        typeName: ({ node, object, isArray }) => {
          const oldName = _.upperFirst(
            _.camelCase(`${path.basename(node.dir)} Json`)
          );

          const newName = `x${oldName}`;  // just add x to every node
          console.log(`${oldName} => ${newName}`);
          return newName;
        },
      },
    }

That being said it'd still be great to give a better error message than

UNHANDLED REJECTION Syntax Error: Unexpected Int "20"

I don't think that error message is going to lead most people to quickly figure out what's wrong. It probably also wouldn't hurt to drop some info on the gatsby-transformer-json plugin doc about this situation. But that probably belongs in another issue?

[pieh]

That being said it'd still be great to give a better error message than

UNHANDLED REJECTION Syntax Error: Unexpected Int "20"

Agreed! Tho we wouldn't be able to provide much context anyway, but we could print that data (nodes) created by plugin X (we know which plugin owns particular node types) have invalid type. While we couldn't provide hints on how to fix it (using typeName in this case is gatsby-transformer-json speicifc), we could at least narrow it down to particular plugin.

As for documention - we probably could have Troubleshooting section in gatsby-transformer-json mentioning current error and way to handle that (but also would need to make a note to update it when we would have nicer error in gatsby core)

[sakhmedbayev]

I am getting into the same issue:

GraphQLError: Syntax Error: Invalid number, unexpected digit after 0: "0".

file name:

000-hello.json

[LekoArts]

Closing this as stale since in the meantime Gatsby v3 and updated related packages were released. Please try with the latest versions and if you still see this problem open a new bug report (it must include a minimal reproduction).