New: import .graphql files in Meteor!

It’s now possible to import .graphql files directly in Meteor!

Installation

meteor add swydo:graphql

Usage

Create a .graphql file, like getPerson.graphql:

query getPerson {
  person(id="1"): {
    name
    age
  }
}

Now simply import it in your javascript:

import query from './getPerson.graphql';

// See https://github.com/apollographql/apollo-client for setup
const client = new ApolloClient();

// The query is parsed and can be directly passed to the Apollo Client
client.query({ query }).then(console.log);

You can also import your main schema and pass it directly to makeExecutableSchema:

import { makeExecutableSchema } from 'graphql-tools';

import typeDefs from './schema.graphql'; // No need to parse it!
import resolvers from './resolvers';

const schema = makeExecutableSchema({
  typeDefs,
  resolvers,
});

.graphql, .graphqls and .gql files are supported.

Benefits

There are some good reasons to use .graphql files instead of the inline syntax:

16 Likes

Works out of the box with babel plugin inline import.
Just install the plugin with npm and add this to .babelrc

{
“plugins”: [
[“babel-plugin-inline-import”, {
“extensions”: [
".graphqls",
".graphql"
]
}

2 Likes

The difference is that inline import will just load the string and won’t do any processing on it right?

Thanks for the info @vraptor. I haven’t tried it myself, but can you confirm if it returns just the string or an AST? If it’s just a string it will work with makeExecutableSchema, but maybe give some issues for normal queries. Not sure when you would use imports for queries though…

At the moment the server will error if you add an empty .graphql file. Most people will start with an empty file though so I think it should simple export nothing in that case instead of showing a parsing error.

What do you all think?

Edit: done! 0.0.3 will not stop your server when you add a new empty .graphql file!

1 Like

I made a fork of babel-plugin-inline-import that returns the AST and supports fragments. Haven’t tested it with Meteor but it should work.

1 Like

Does anyone know what sublime plugin to use for graphql file syntax highlighting?

Hi all, just an update on the current state of the package:

Field Descriptors

We added support for field descriptors, so this now works:

# This is just a normal comment

# This is a description of the type Person
# So you can see this in GraphiQL
type Person {
  # This is a description of name
  name: String
  # And this says something about email
  email: String
}

Error handling

The package now also handles parsing failures better in you .graphql files and reports them nicely, showing you the exact file, line number and column in your console.

As always, any feedback and bug reports are welcome.

Cheers

What’s the difference between .graphql, .graphqls and .gql files ?

.graphql is the official extension although .gql is sometimes used too. Those two are equivalents, but I barely see .gql being used anymore.

.graphqls is sometimes (rarely) used for pure schema files, so without query or mutation calls. Only type definitions.

I recommend to always use .graphql. I added the other 2 for people using those extensions, so it wouldn’t block them from using the package.

3 Likes

So, do you need a separate graphql for each query/mutation/typeDef? It looks like you can only export default one thing?

Like do I need to break the below es6 string into 7 files? I can’t access each type separately, and if I do

import * as BaseSchemas from './BaseSchema.graphl

import BaseSchemas from './BaseSchema.graphl

I still get errors.

export const BaseSchemas = [
  `
type Geometry {
	    type: String!
	    coordinates: [Int]
	}

scalar Date

type Count { 
  count: Int
}

type BooleanResult { 
  result: Boolean
}

input LocationData {
	street1: String
	street2: String
	postal: String
	country: String
	city: String
	state: String
	suburb: String
}

input ImageObject {
	fileType: String
	name: String
	uid: String
	url: String
}

type Address {
	    fullAddress: String!
	    lat: String
	    lng: String
	    geometry: Geometry
	    placeId: String
	    street: String
	    city: String
	    state: String
	    zip: Int
	    country: Int
	    maps_url: String
	}
`,
];

On the client, I have so many queries and mutations, I don’t really want 100 different graphql files.

I’ll need some more information, because import BaseSchemas from './BaseSchema.graphl should Just Work™

You don’t have to for types, although separating some of them is sometimes better to keep things organized. I do work with separate files for each query and mutation. You might end up with quite a few of them, but I don’t see the issue in that. I can add a query in a specific module, package or directory, close to where it is used. I wouldn’t want one big file with everything in it, just like I don’t want one file with all code in it.

Could you file an issue in the repo with details about package versions so I can reproduce? Or make a reproduction yourself that I can fork.

In general I would recommend reporting the issue in the repo itself :+1:

Cheers

Looks like there is work being done on multiple exports: https://github.com/apollographql/graphql-tag/pull/122

The swydo:graphl package is based on graphql-tag, so any features added there will eventually end up in swydo:graphql.

1 Like

Yes, please provide feedback and contribute on that PR!

I would love to see those errors, because I’m not able to reproduce. Could you file a bug report at Issues · Swydo/meteor-graphql · GitHub ?

Edit:
@a.com I just noticed you added export const BaseSchemas = [ ... ] around your schema, but you don’t have to do that in a .graphql file. This will for certain create errors. A .graphql file doesn’t need an export statement.

Also, did you know you can use import statements in a schema file?

#import "./personSchema.graphql"

type Query {
  # It will recognize the Person type from the personSchema.graphql file
  person(id): Person
}

Multiple queries in one file

Good news! It’s now possible to import multiple queries from the same file! :tada:

# queries.grahql

query foo {
    baz
}

query bar {
    baz
}
import { foo, bar } from './queries.graphql';

const client = new ApolloClient();

client.query({ query: foo }).then(console.log);

String descriptors

It now also supports string descriptors, the official new way to add descriptions to your types. This means the example above will now look like this:

# This is just a normal comment

"""
This is a description of the Person type
So you can see this in GraphiQL
"""
type Person {
  "This is a description of name"
  name: String
  "And this says something about email"
  email: String
}

And a side note: the previous descriptors didn’t show up in GraphiQL. Sorry about that. These officially supported descriptors will actually show up. Enjoy!

Upgrade

To start using these new features:

meteor add swydo:graphql@0.4.0
3 Likes

Does this package also work with interface? i.e

# node.graphql
interface Node {
  id: ID!
}

# user.graphql
#import './node.graphql
type User implements Node {
  id: ID!
  name: String!
  age: Int!
}

Because i tried it, and got
type node could not be found in the document.

I see you reported the ticket on GitHub. We’ll continue from there :+1: