dfreeman/broccoli-graphql-filter

Converts GraphQL files to a JS file exporting an AST

Oops. Now I'm kind of obligated to put something here, aren't I?

broccoli-graphql-filter's Issues

Allow importing files with .graphql

It would be very nice if this project generated modules that are compatible to importing with the suffix .graphql.

For these using TS, it is easier to make TS happy if we import it with an extension.

So, let's say we have a file called account.graphql.

Today, we would import it using:

import accountQuery from './account';

What I would like to have is:

import accountQuery from './account.graphql';

Same goes for importing fragments inside of graphql files.

seems to be watching other extensions

strange error:

Build Error (broccoli-persistent-filter:GraphQLFilter)

ENOENT: no such file or directory, lstat '/Volumes/RAMDisk/broccoli-66933e1XKQk9MrS7O/out-700-funnel/maestro/styles/modals.scss'


Stack Trace and Error Report: /Volumes/RAMDisk/error.dump.8e0dcf69bc3d32547f1147716edc3a28.log

why would this be concerned with a scss file?

Fragment can't be imported more than once

I noticed that a particular fragment can't be imported more than once.

This becomes a bit confusing in cases where a fragment imports a fragment. I think importing the fragment a second time should result in a no-op rather than an error around the fragment being defined more than once.

Is this something you'd be interested in a PR to fix? If so, I would be happy to put one together!

Thoughts on syntax parity with graphql-import?

The graphql-import library uses a similar but incompatible syntax.

broccoli-graphql-filter

#import from 'some/runtime/path'

graphql-import

# import FragmentName from 'some/node-resolvable/path'

I'm interested in parity because I would like to use tools like apollo client:extract on the queries in my Ember app. Currently they fail with a syntax error.

This is obviously not a trivial change. I can foresee two issues:

1. The path in the broccoli #import statement doesn't map to a file on disk so graphql-import couldn't use it anyway. (graphql-import uses resolve-from to find files.) We'd need a way to teach graphql-import about Ember's file system layout, wait for ef4's new builder spec to land, or ...?.

2. The graphql-import syntax matches ES6 module imports, including import specifiers. This is more complicated than broccoli-graphql-filter, which is effectively the same as import * as AllFragments from 'path'. Dealing with aliases (import { foo as bar }) is considerably more complicated.

   This project could limit itself to supporting only * as AllFragments for simplicity's sake.

Thoughts? I wish I had a real solution for point number 1!