Import & export definitions in GraphQL SDL
GraphQL Import has been deprecated and merged into GraphQL Tools, so it will no longer get updates. Use GraphQL Tools instead to stay up-to-date! Check out https://www.graphql-tools.com/docs/migration-from-import for migration and https://the-guild.dev/blog/graphql-tools-v6 for new changes.
![greenkeeper[bot] avatar](https://avatars.githubusercontent.com/in/505?v=4 "greenkeeper[bot]")
![renovate[bot] avatar](https://avatars.githubusercontent.com/in/2740?v=4 "renovate[bot]")
Either directly, or using a separate method. I think it's very helpful to perform standard schema validation. If you agree, I have some WIP on the matter using the standard graphjs/validate method with some custom rules.
Hi. I trying import file containt directives. After import, directive filtered from the output.
I've heard people asking about the option to import from HTTP endpoints. While this is convenient in simple scenarios, most real-world applications require you to have your schema available locally avoiding the heavy network overhead to download the schema definition from a remote server.
I leave it up for discussion whether this should be implemented or not.
Hello!
I'm using your awesome library to split my server-sice (NodeJS & TypeScript) code.
Unfortunately I faced an issue with import.
I have this .graphql file:
type Query {
users: String
}
type AuthMutation {
authenticate(code: String!, accountId: String): String
}
schema {
query: Query,
mutation: AuthMutation
}
And I'm trying to import it in this way:
import { importSchema } from 'graphql-import';
import * as path from 'path';
const AuthSchema = importSchema(path.join(__dirname, './auth.graphql'));But I'm getting an incorrect result:
type Query {
users: String
}
type AuthMutation {
authenticate(code: String!, accountId: String): String
}
No schema. Any suggestions on this?
Thank you!
I'm currently using the snippets below as a custom Webpack loader, as it makes more sense for me to handle the graphql import resolution at compile time (I'm using a serverless-webpack + typescript setup)
Adding a native webpack loader to the npm package might be helpful for Webpack projects.
// ./graphql-import-loader.js
const { importSchema } = require('graphql-import')
module.exports = (source) => {
this.value = source
return `module.exports = \`${importSchema(source)}\``
}// webpack.config.js
...
module: {
rules: [
{
exclude: /node_modules/,
test: /\.(gql|graphql)$/,
use: [
{
loader: require.resolve('./graphql-import-loader'),
// loader: 'graphql-import/loader', // this is what i'm proposing
},
]
},
...// server.ts
import { GraphQLServerLambda } from 'graphql-yoga'
import { Prisma } from './generated/prisma'
import typeDefs from './schema.graphql'
import resolvers from './schema/resolvers'
const {
graphqlHandler,
playgroundHandler,
} = new GraphQLServerLambda({
typeDefs,
resolvers,
context: req => ({
...req,
db: new Prisma({
endpoint: 'https://eu1.prisma.sh/.../test-api/dev',
secret: 'mysecret123',
debug: true,
})
})
})
export {
graphqlHandler,
playgroundHandler,
}
// custom typings
declare module '*.graphql' {
const content: any
export default content
}I get this in logs when I try to use it with amazon lambda:
module initialization error: Error
at Error (native)
at Object.fs.openSync (fs.js:641:18)
at Object.fs.readFileSync (fs.js:509:33)
at read (/var/task/node_modules/graphql-import/dist/index.js:10:19)
at importSchema (/var/task/node_modules/graphql-import/dist/index.js:57:15)
at Object.<anonymous> (/var/task/handler.js:176:48)
at __webpack_require__ (/var/task/handler.js:20:30)
at Object.<anonymous> (/var/task/handler.js:91:15)
at __webpack_require__ (/var/task/handler.js:20:30)
at /var/task/handler.js:63:18
Hello thanks for this work. I am trying to to run tests with Jest but they are failing when i have an import statement inside my schema to import another graphql type def.
Any suggestions?
Thanks
Given the following schemas:
# schemaC
type C1 {
id: ID!
}
type C2 {
id: ID!
}
type C3 {
id: ID!
}
# schemaB
# import * from 'schemaC.graphql'
type B {
hello: String!
c1: C1
c2: C2
}`
#schemaA
# import * from "schemaB.graphql"
type A {
# test 1
first: String @first
second: Float
b: B
}The resulting schema contains all types from all schemas, even though C3 is not used.
Now changing the import in schema A to:
#schemaA
# import B from "schemaB"
type A {
# test 1
first: String @first
second: Float
b: B
}Suddenly, C3 is correctly filtered out.
I would expect to load these through my application rather than import schema's in my graphql files.
Instead I get:
Error: Field event: Couldn't find type GraphQLUUID in any of the schemas.
at collectNode (/Users/XXX/XXX/XXX/XXX/XXX/XXX/node_modules/graphql-import/src/definition.ts:154:15)
at /Users/XXX/XXX/XXX/XXX/XXX/XXX/node_modules/graphql-import/src/definition.ts:135:7
at Array.forEach (<anonymous>)
at collectNewTypeDefinitions (/Users/XXX/XXX/XXX/XXX/XXX/XXX/node_modules/graphql-import/src/definition.ts:134:26)
at Object.completeDefinitionPool (/Users/XXX/XXX/XXX/XXX/XXX/XXX/node_modules/graphql-import/src/definition.ts:49:39)
at importSchema (/Users/XXX/XXX/XXX/XXX/XXX/XXX/node_modules/graphql-import/src/index.ts:106:26)
I use graphql-import to load graphql schema written in separate file. I have more than 40+ individual schema files however with surprise it doesn't recognize Contact type I have. Following are more details.
// contact.graphql
type Contact {
firstName: String
lastName: String
email: String!
phoneNumber: String
}
// seller.graphql
# import Contact from './contact.graphql'
type Seller {
sellerId: String!
name: String
image: String
contact: Contact # Somehow not able to find Contact type
}Note: contact.graphql and seller.graphql are in same directory
Following is code to import schema.
const { importSchema } = require('graphql-import');
// Load GraphQL schema from files
const typeDefs = importSchema('./typedef/index.graphql');While running server, I get following error. I have no clue why? Any help will be appreciated.
/Users/****/workspace/my-project//node_modules/graphql/utilities/buildASTSchema.js:134
throw new Error('Type "' + typeRef.name.value + '" not found in document.');
^
Error: Type "Contact" not found in document.
at ASTDefinitionBuilder._resolveType (/Users/****/workspace/my-project/node_modules/graphql/utilities/buildASTSchema.js:134:11)
at ASTDefinitionBuilder.buildType (/Users/****/workspace/my-project/node_modules/graphql/utilities/buildASTSchema.js:218:79)
at ASTDefinitionBuilder._buildWrappedType (/Users/****/workspace/my-project/node_modules/graphql/utilities/buildASTSchema.js:227:24)
at ASTDefinitionBuilder.buildField (/Users/****/workspace/my-project/node_modules/graphql/utilities/buildASTSchema.js:248:18)
at /Users/****/workspace/my-project/node_modules/graphql/utilities/buildASTSchema.js:302:21
at /Users/****/workspace/my-project/node_modules/graphql/jsutils/keyValMap.js:28:31
at Array.reduce (<anonymous>)
at keyValMap (/Users/****/workspace/my-project/node_modules/graphql/jsutils/keyValMap.js:27:15)
at ASTDefinitionBuilder._makeFieldDefMap (/Users/****/workspace/my-project/node_modules/graphql/utilities/buildASTSchema.js:299:49)
at fields (/Users/****/workspace/my-project/node_modules/graphql/utilities/buildASTSchema.js:284:23)The title's confusing, so I'll just give an example.
# sample.graphql
# import Foo from 'foo'
type Query {
foo: Foo
}
// index.js
const {readFileSync} = require('fs');
const {importSchema} = require('graphql-import');
const fooSchema = `
type Foo {
id: ID!
}
`
// This works.
importSchema(readFileSync('./sample.graphql', 'utf8'), {foo: fooSchema});
// This throws.
importSchema('./sample.graphql', {foo: fooSchema});
The issue is that it tries to pull dirname/foo from schemas.
I was working on a project that started from the boilerplate and hence my schema has the following line at the top
# import Post from "./generated/prisma.graphql"
Initially, I mistook this for a comment (because #, coloring from my editor) but later I ran into graphql-import and understood that this is an import.
What I noted was that import is not required as I am able to use other types from prisma.graphql without having to import them explicitly.
Is this behavior expected? I spoke to @marktani about it and he recommended that I should raise the issue here.
A snippet of my schema.graphql would look like this
# import Post from "./generated/prisma.graphql"
type Query {
getUser(id: ID!): User
getPost(id: ID!): Post
}
Notice that I have only imported Post from prisma.graphql but I am able to use User as well without explicitly importing it.
In the last GraphQL working group meeting we discussed to enable GraphQL directives on a document/root level. This would allow for the following syntax which avoids the common "why is it commented out" confusion around graphql-import:
@import(defs: [Post, Comment] from: "./other-types.graphql")
@import(defs: Message from: "./msg.graphql")
type User {
id: ID!
}@import, defs:, from:When using graphql-import together with a Prisma Service, a common situation that a developer finds herself in is copying over type names.
This happens when you just want to "forward" the underlying service types to the resulting application schema.
While the current explicit nature of graphql-import provides good readability and maintainability, it requires in certain cases a lot of boilerplate code.
To make it possible for developers to have quicker iterations on schemas, we should introduce an automatic import mechanism.
That means, that any type used in the resulting schema, that is not defined, will be searched in specified source files.
The API could look like this:
const typeDefs = importSchema('schema.graphql', ['./generated/source.graphql'])schema.graphql
type A {
# test 1
first: String
second: Float
b: B
}./generated/source.graphql
type B {
hello: String!
}Anyone interested working on this, please answer in this issue or join our public Graphcool slack!
I have to do this to make this module works (ardatan/graphql-tools#273 (comment))
import { importSchema } from 'graphql-import';
import * as path from 'path';
export const typeDefs = importSchema(path.join(__dirname, './schema.graphql'));if I did as the example, i will be got:
ENOENT: no such file or directory, open 'schema.graphql'
at Object.fs.openSync (fs.js:646:18)
at Object.fs.readFileSync (fs.js:551:33)
at read (node_modules/graphql-import/dist/index.js:8:37)
at Object.importSchema (node_modules/graphql-import/dist/index.js:29:15)
at Object.<anonymous> (src/graphql/index.ts:9:37)
at Object.<anonymous> (src/graphql/__tests__/schema.test.ts:3:15)node: v8.9.1
npm: 5.5.1
E.g.
# schema.graphql
# import Mutation.createUser from "....../generated/prisma.graphql"
....
# import * from "./post/post.graphql"
...
# post.graphql
# import Mutation.createPost from "....../generated/prisma.graphql"
...
will not import Mutation.createPost or throw an error. Please let me know if an example repo would help. Thank you!
Assume
main.graphql
# import * from "./User.graphql"
type Query {
apiVersion: String!
}
User.graphql
type User {
name: String!
}
extend type Query {
me: User!
}
In resulting compiled schema Query has only version. There is no me field added.
I'm receiving the error:
Error: Query root type must be provided
Here is my schema:
schema.graphql
schema {
query: ClientQuery
...
}
type ClientQuery {
...
}
I am importing it with graphql-importer
import { importSchema } from 'graphql-import'
const baseTypeDefs = importSchema('../pg-fresh-client/schema/schema.graphql')
Shouldn't this be valid?
I am trying to make use of graphql-import with typescript, It loads files fine but I still have to find a way to copy the .qraphql files to a dist folder... which mean involving some more complex build steps. And the idea of maintain both a *.graphql version and *.graphql.ts version is not ideal.
While I haven't considered all the other existing proposals and how they might solve this, I'm considering trying out something like the following, to achieve the functionality i desire:
Folder structure for a singe entity
- Book
-- index.ts
-- query.qraphql
-- query.qraphql.ts
-- resolver.ts
-- schema.qraphql
-- schema.qraphql.ts
*.qraphql.ts
import { importSchema } from "graphql-import"
export const Query:string = importSchema(__dirname + '/' + __filename.replace('.ts',''));
when I build i want to take the *.qraphql content loaded and replaces the importSchema with the actual graphql schema/query string. so that the dist folder will contain a baked version of the graphql schema/query at build time.
Thoughts?
EDIT: Better yet, potentially I can build cli tool that makes use of this module to watch files and bake them into .js / .ts files that export the graphql schema/query string on change.
# import Query.* from '....'
# import Query.posts from '....'
etc.
Importing files with circular dependencies does not work when importing multiple .graphql files.
I wrote some simple functionality that is broken up into multiple files. The code below - user and team both relate to each other.
const { importSchema } = require('graphql-import');
const path = require('path');
const team = importSchema(path.join(__dirname, 'team.graphql'));
const user = importSchema(path.join(__dirname, 'user.graphql'));
const query = importSchema(path.join(__dirname, 'query.graphql'));
const schema = importSchema(path.join(__dirname, 'schema.graphql'));
module.exports = [
user,
team,
query,
schema
];I then tested the same code in a single file.
const { importSchema } = require('graphql-import');
const path = require('path');
const schema = importSchema(path.join(__dirname, 'schema.graphql'));
module.exports = [
schema
];Single schema file
schema {
query: Query
}
type Query {
users: [User]
user: User
teams: [Team]
team: Team
}
type Team {
name: String
description: String
users: [User]
}
type User {
firstName: String
lastName: String
teams: [Team]
}
This works. Any chance this can be extended to work with multiple files?
The current Prisma full-stack boilerplates are basically separated into two parts: the actual Prisma service with it's data model and the front-facing GraphQL API which sits on top. Having those two components in one project is very good for development, because you can use the Prisma CLI in order to deploy it to a local cluster a.k.a. run it as local Docker containers. For production I envision a slightly different scenario. Here I would love to deploy the actual Prisma service as a separate unit and let my front-facing GraphQL API fetch the Prisma schema from that deployed service.
So instead of importing the generated schema via
# import Post from "./generated/prisma.graphql"
I would like to import it directly from the Prisma service endpoint, like
# import Post from "http://my-prisma-endpoint:4466"
In the end, this would result in a more flexible way of approaching different deployment scenarios, like deploying a Prisma service to Mesos or Kubernetes.
I would love to hear your thoughts :)
Hey guys,
Nice work with this module, but there was one issue I spotted. It seems that the parsing removes in-line comments that are intended to be documentation for GraphiQL.
As an example, say I have this type
# import User from "User.graphql"
# The top level query for this GraphQL server
type Query {
# A desc
current_user: User
# Another desc
jobs: [String]
}It turns out like so after importSchema does its thing:
type Query {
current_user: User
jobs: [String]
}I'm guessing as part of post processing, this library just outright strips comments...do we have an escape hatch to maintain comments, or did I just totally miss something?
Thanks!
@nickluger commented on Fri Feb 23 2018
prisma.graphql in it:# import DateTime from "./generated/prisma.graphql"
type Foo{
bar: DateTime
}yarn graphql prepare -p app --output src/generated -g binding-ts --bindings --bundle --saveor just yarn graphql prepare if you have a proper definition in your graphqlconfig.yml
Mine looks like this
projects:
app:
schemaPath: "src/schema.graphql"
extensions:
prepare-binding:
output: src/generated/app.ts
generator: binding-ts
endpoints:
default: "http://localhost:4000"
database:
schemaPath: "src/generated/prisma.graphql"
extensions:
prisma: database/prisma.yml
prepare-binding:
output: src/generated/prisma.ts
generator: prisma-ts
Result:
✖ Generating bindings for project app...
Type "DateTime" not found in document.
graphql-relay-tools is a "library that allows the easy creation of Relay compliant servers using the GraphQL type language", used in conjunction with graphql-tools. It provides helper functions for dealing with Relay connections, object identification, etc.
graphql-relay-tools & graphql-tools both assume that you're defining your types, etc using JavaScript templated strings, and uses interpolation to call its functions. For example,
const factionType = `
type Faction {
ships${connectionArgs()}: ShipConnection
}
`;… would result in the following GraphQL type:
type Faction {
ships(
first: Int,
after: String,
last: Int,
before: String
)
}: ShipConnectionRight now, I can't see a way to use this pattern with static .graphql files and graphql-import. Am I missing something? If not, is this something that would be considered as an addition to the library?
I've tried to split my whole schema to be able to put the schema-parts and corresponding resolvers together.
I ended up with a file structure like this:
├── generated
├── resolvers
| ├── User
| | ├── queries.ts
| | ├── mutations.ts
| | └── user-schema.graphql
| ├── Post
| | ├── queries.ts
| | ├── mutations.ts
| | └── post-schema.graphql
| └── index.ts
└── complete-schema.graphql
And schemas looking like this:
user-schema.graphql
# import Post from "../../generated/graphcool.graphql"
type User {
id: ID!
email: String!
name: String!
posts: [Post!]!
}
type Query {
me: User
}
...My main schema ended up being empty (except for the import statements):
complete-schema.graphql
# import Query.*, Mutation.* from './resolvers/Post/post-schema.graphql'
# import Query.*, Mutation.* from './resolvers/User/user-schema.graphql'Which leads to an Syntax Error: Unexpected <EOF>.
It only works if I change the schema to:
complete-schema-working.graphql
# import Query.*, Mutation.* from './resolvers/Post/post-schema.graphql'
# import Query.*, Mutation.* from './resolvers/User/user-schema.graphql'
# We need at least one 'real' definition or things go south ;)
type Dummy {
dummy: String!
}It would be great if we could use files that consist only of import statements without having to add dummy-types.
Now we have 100 test coverage, we can automerge all deps.
Also, let's setup a code coverage integration (preferably coveralls) to report on PR's.
Using this library i got the following error when trying to run an graphql-express server:
GraphQLError: Syntax Error: Cannot parse the unexpected character "/".
Using a typedefs as a string and using only graphql-tools i got the following error:
Error: "login" defined in resolvers, but not in schema
Much easier to understand what went wrong.
Is it possible to expose these kinds of errors to the user when using graphql-import?
Hello!
I'm running into an issue possibly related to cyclic dependencies. Any Help would be really appreciated.
Here's a simple example of what I'm trying to do:
# a.graphql
# import B from "b.graphql"
type A {
someField: String!
bs: [B]
}# b.graphql
# import A from "a.graphql"
type B {
someField: String!
a: A
}Here's the error I'm getting once I start the application. Am I doing something wrong?
/path/to/project/node_modules/graphql-import/node_modules/graphql/index.js:330
return _language.parse;
^
RangeError: Maximum call stack size exceeded
at Object.get [as parse] (/path/to/project/node_modules/graphql-import/node_modules/graphql/index.js:330:21)
at collectDefinitions (/path/to/project/node_modules/graphql-import/dist/index.js:39:29)
at /path/to/project/node_modules/graphql-import/dist/index.js:43:16
at Array.map (native)
at collectDefinitions (/path/to/project/node_modules/graphql-import/dist/index.js:41:63)
at /path/to/project/node_modules/graphql-import/dist/index.js:43:16
at Array.map (native)
at collectDefinitions (/path/to/project/node_modules/graphql-import/dist/index.js:41:63)
at /path/to/project/node_modules/graphql-import/dist/index.js:43:16
at Array.map (native)
at collectDefinitions (/path/to/project/node_modules/graphql-import/dist/index.js:41:63)
at /path/to/project/node_modules/graphql-import/dist/index.js:43:16
at Array.map (native)
at collectDefinitions (/path/to/project/node_modules/graphql-import/dist/index.js:41:63)
at /path/to/project/node_modules/graphql-import/dist/index.js:43:16
at Array.map (native)
error Command failed with exit code 1.It will run start and run as expected if the types are in the same file, but I have quite a few types with a large number of fields, so I would like to keep things broken-out as a file for each type.
Any thoughts?
thanks!
Proposal (based on #13, #14 and #15):
Add optional parameter to importSchema:
rules? : {
removeUnusedTypes?: boolean = true,
importAllInterfaceImplementations?: boolean = false,
importMissingTypes?: boolean = true,
orderTypes?: boolean = false,
strict?: boolean = true,
validate?: boolean = false
}Most are self-explanatory, strict: true would fail on missing schema files or missing imported types, otherwise silently ignored. validate: true would run the linter.
Hi, thanks for the library! starting to use it to break apart my schema file, looks very promising
Small question, would you be open to changing this line?
https://github.com/graphcool/graphql-import/blob/master/src/index.ts#L63
.filter(l => l.startsWith('# import') || l.startsWith('#import'))
to (ie spaces after import)
.filter(l => l.startsWith('# import ') || l.startsWith('#import '))
Our team have a tendancy to add comments lines like this:
#importent: DONT add types that will causes import cycles
And those lines get rejected by here:
https://github.com/graphcool/graphql-import/blob/master/src/index.ts#L39
For the following schema in a.graphql
type Query {
feed: [Post!]!
me: User
}
I'd like to be able to do something like this:
In b.graphql
# import Query.feed from "a.graphql"
and that query automatically gets appended to my other queries in b.graphql
Interface implementations:
I don't understand the intended behavior of the interface-implements fixture. Why is it expected that when importing an interface, graphql-import does also import all implementations of that interface?
Missing types
If you import a Type, that has fields of a Type that is not imported, that Type gets imported automatically. I think this kind of implicit behavior should not happen.
'Tree shaking'
It seems graphql-import does some tree shaking, if you do import * but one of the types from the imported file is not used. Again, I think this kind of implicit behavior should not happen.
Hi, I have an idea/suggestion. I find it a little bit tedious to always copy/paste my graphql datamodels from the prisma backend to the server graphql type definition file, 90% of my models are reused anyway. Wouldnt it be possible to simply add an anotation like "expose" and "private" to the prisma type definitions and their parameters and include the types in the code generation process? with default to "private", this would not change the current behavior and could be handy to quickly export the types you want to expose from prisma in a DRY manner without having to copy paste the common types all the time. additionally, it might be nice to also make overriding these in the server portion of the app a more conscious process with an "extends" or "overrides" annotation or keyword on altering type definitions.
The last release seems to be broken. I had a database schema with a Post type and was referencing it from my application schema like so:
# import Post from "../database/schema.graphql"
type Query {
feed: [Post!]!
post(id: ID!): Post
}
type Mutation {
createPost(description: String!, imageUrl: String!): Post!
deletePost(id: ID!): Post
}When running the app, I got the error message that the Post type was not found in any of the schemas.
Rolling back to version 0.1.5 fixed the problem.
Allow the following:
# import Repository from "github-graphql-binding"
type Query {
repo: Repository
}This could potentially break the existing API by enforcing ./ for local imports.
Would be great to hear more thoughts on this feature proposal!
@schickling Please revert commit 964a670. The now.json file is copied to the docs folder for deployment, which is now broken.
Consider the example from graphql-binding-github.
# import Repository from "./github.graphql"
type Query {
hello(name: String): String!
favoriteRepos: [Repository!]!
}
It requires an up to date github.graphql, which is generated, to exist next to app.graphql, which is not. github.graphql also has to be put into version control and manually regenerated whenever the GitHub GraphQL endpoint is updated.
However, graphql-binding-github exports a github.graphql. Using that, I wouldn't have to put it in version control or regenerate it, just update graphql-binding-github. But, rewriting it that way comes with another problem.
# import Repository from "../node_modules/graphql-binding-github/schema/schema.graphql"
Things get even hairier if app.graphql is deeply nested or in a monorepo.
Ideally, I should be able to do something like
# import Repository from "graphql-binding-github/schema/schema.graphql"
To take it a step further, you could default to a top-level schema.graphql or use a graphql:main field in the package.json and do something like
# import Repository from "graphql-binding-github"
I believe this is currently possible with Object Imports, but you'd have to do something like
const githubSchema = fs.readSync('Path to schema.graphql');
importSchema(mySchema, {'graphql-binding-github': githubSchema});
FYI, I initially raised this issue on graphql-yoga.
I setup a repository with an example of the issue I am running into: https://github.com/loicplaire/graphql-yoga-engine-issue
When I use the @cacheControl directive in my schema.graphql file, I get the following error:
/git/graphql-yoga-engine-issue/node_modules/graphql-import/dist/definition.js:113
throw new Error("Directive " + directiveName + ": Couldn't find type " + directiveName + " in any of the schemas.");
^
Error: Directive cacheControl: Couldn't find type cacheControl in any of the schemas.
at collectDirective (/git/graphql-yoga-engine-issue/node_modules/graphql-import/dist/definition.js:113:23)
at Array.forEach (<anonymous>)
at collectNewTypeDefinitions (/git/graphql-yoga-engine-issue/node_modules/graphql-import/dist/definition.js:47:34)
at Object.completeDefinitionPool (/git/graphql-yoga-engine-issue/node_modules/graphql-import/dist/definition.js:23:41)
at Object.importSchema (/git/graphql-yoga-engine-issue/node_modules/graphql-import/dist/index.js:85:41)
at mergeTypeDefs (/git/graphql-yoga-engine-issue/node_modules/graphql-yoga/dist/src/index.js:320:37)
at new GraphQLServer (/git/graphql-yoga-engine-issue/node_modules/graphql-yoga/dist/src/index.js:85:34)
at Object.<anonymous> (/git/graphql-yoga-engine-issue/index.js:16:16)
at Module._compile (module.js:643:30)
at Object.Module._extensions..js (module.js:654:10)My assumption is that graphql-import only understands built-in directives or directives directly imported in the schema.graphql file.
In that case how would I import the cacheControl directive from apollo-cache-control in my .graphql files when this doesn't seem to be exported by this package? Would I have to redeclare it?
Thanks!
Given these GraphQL files:
all.graphql
# import Query.first, Query.second from "a.graphql"
# import Query.third from "a.graphql"a.graphql
type Query {
first: String
second: Float
third: String
unused: String
}The actual output is:
type Query {
first: String
second: Float
}But the expected output is:
type Query {
first: String
second: Float
third: String
}In this simple scenario you'd perhaps say: just merge those two imports together. However, this is of course a reduced test case. I want to make a separate file per entity (e.g. user, restaurant) and per file, import the generated Prisma file # import Query.user from "generated/prisma.graphql".
I have also written a failing test. If you'd like I can make a PR with the failing test. I don't know enough about this package to fix it myself though.
As a next step importing can also be implemented at build time using Babel or Webpack.
In the docs on https://graphql-import.now.sh, there's a clickable link to https://graphql-import.now.sh/src/index.test.ts, which returns 404.
I have a little bug about the syntax in Visual Studio Code, because one comment isn't generated to the new line:
This is the actual render in VSC:
It seems that the """ comment tag must start in a new line to avoid the IDE to misunderstand the color syntax (see the minimap on the right)
It must be like this:
Thanks 😀
(PS: maybe also about the VSC plugin to graphQL syntax because I don't have it for Atom)
Currently the only way to rename types in a schema is not import them, but create a new type and copy the fields. It would be very useful if one could do:
# import House as Home from './mySchema.graphql'
If the top level schema name is passed in as a file, say src/schemas/user.graphql, and user.graphql only has a single import #import * from 'shared', and the schemas map is { shared: sharedSchemaString } an error occurs:
TypeError: Cannot read property 'split' of undefined
at isEmptySDL (node_modules/graphql-import/dist/index.js:123:10)
at getDocumentFromSDL (node_modules/graphql-import/dist/index.js:105:9)
at collectDefinitions (node_modules/graphql-import/dist/index.js:148:20)because this line: https://github.com/graphcool/graphql-import/blob/master/src/index.ts#L200 returns
path.resolve(path.join(dirname, m.from)) instead of m.from.
I don't think it should operate this way since my import does not end with .graphql, and therefore the string should come from the map.
If this is a valid issue, I can make a PR to fix the bug 😄
I can currently get around this bug by changing my schema map from:
{ 'shared': shared }to
{ [path.join(process.cwd(), 'src/schemas/shared')]: shared }however that is not an obvious solution
I want to "comment out" import statements, how does that work?
What about this:
# import User from file.graphql
# # add later:
# # import Post from invalid.graphqlmaster branch failed. 🚨I recommend you give this issue a high priority, so other packages depending on you could benefit from your bug fixes and new features.
You can find below the list of errors reported by semantic-release. Each one of them has to be resolved in order to automatically publish your package. I’m sure you can resolve this 💪.
Errors are usually caused by a misconfiguration or an authentication problem. With each error reported below you will find explanation and guidance to help you to resolve it.
Once all the errors are resolved, semantic-release will release your package the next time you push a commit the master branch. You can also manually restart the failed CI job that runs semantic-release.
If you are not sure how to resolve this, here is some links that can help you:
If those don’t help, or if this issue is reporting something you think isn’t right, you can always ask the humans behind semantic-release.
semantic-release cannot push the version tag to the branch master on remote Git repository.
Please refer to the authentication configuration documentation to configure the Git credentials on your CI environment.
Good luck with your project ✨
Your semantic-release bot 📦🚀
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.