Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The nature of GraphQL is that it is very easy to end up with circular dependencies. Simply something as
can quickly become problematic. mstGQL currently doesn't allow any elegant way of controlling the import order resulting in some funky behaviour. In my opinion I don't think any of the
.base
files should be separate and would prefer one giantbase.generated.ts
file as it would avoid a lot of the problems but also make it easier with Typescript types on the resolvers etc. But also realise that it probably would be an unpopular move.So instead I followed Westrate's excellent blogpost about use of
internal.ts
barrel files.This change simply makes sure that all the modules now use
import {...} from "./internal"
rather than individual files. You can then use something like barrelsby to generate an internal.ts file that simply exports every module. You can then move around items in that file to control the loading order (Enums at the top etc).This code isn't well tested yet so probably needs a bit of scrutiny before merging, but it works for our repo.