New: import .graphql files in Meteor!

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


meteor add swydo:graphql


Create a .graphql file, like getPerson.graphql:

query getPerson {
  person(id="1"): {

Now simply import it in your javascript:

import query from './getPerson.graphql';

// See 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({

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


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


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”: [


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.


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.


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:


Looks like there is work being done on multiple exports:

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 ?

Edit: 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 {

query bar {
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!


To start using these new features:

meteor add swydo:graphql@0.4.0

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: