Alternative to glob for finding resolvers

[tgomesfork]

Hello there. I see that since the new beta versions, there is a different way to pass the resolvers to build the schema.
In our usecase, we have a complex structure with a lot of dirs and subdirs and this is how we are used to build the schema:

const TYPE_GRAPHQL_FILES = 'src/graphql/*/{types,inputs,queries,mutations,subscriptions}/**/*.[jt]s';
const TYPE_GRAPHQL_FILES_EXCLUDED_PATTERNS = ['**/__tests__/**', '**/__mocks__/**'];

const files = glob.sync(TYPE_GRAPHQL_FILES, { ignore: TYPE_GRAPHQL_FILES_EXCLUDED_PATTERNS });

const { typeDefs: typeDefsFromTs, resolvers: resolversFromTs } = await buildTypeDefsAndResolvers({
  resolvers: files,
  validate: false,
});

We have our resolvers defined on this type of pattern: ['./**/queries/*.ts', './**/mutations/*.ts', './**/subscriptions/*.ts', './**/types/*.resolver.ts']

Is there an easy way to do the kind of glob we were doing, or do we need to start adding index files on all these folders for exporting all the modules just for passing it on the resolvers prop now?

Thanks in advance

[MichalLytek]

The "trick" which was done internally was to call require() and ignore the returned value.
You can do the same "trick" if that works for you - just remember to not ignore the values returned from require() and pass it to the resolvers. I guess a wise choice would be to export them as default, so you can easily reference them.

It's not built-in anymore and users/consumers are required to provide a logic for that because this dummy solution with require does not work with bundlers and others, polluting global metadata storage, so some feature like multiple schemas build with no leaks were not possible.

I think I will do a basic example for 80% of cases in the migration guide doc.

[tgomesfork]

I think the example for this case is a good addition as I think a lot of people were using this way of importing resolvers.

Thanks, I got it working with the require.
On another note, any idea why the generated schema now generates newline character instead of applying it?

-  """
-  Get the custom reservation list configuration
-  Capability required: `custom_reservation_list`
-  """
+  "\nGet the custom reservation list configuration\nCapability required: `custom_reservation_list`\n"

[tgomesfork]

I see something has changed on defining multi-line descriptions.
Previously we were able to define them like this:

@Query(() => CustomReservationList, {
  description: `
    Get the custom reservation list configuration
    Capability required: \`custom_reservation_list\`
  `,

Now to get the proper printed schema, we need to put the \n ourselves on the description:

  @Query(() => CustomReservationList, {
    description: `Get the custom reservation list configuration\nCapability required: \`custom_reservation_list\``,
    nullable: true,
    deprecationReason: 'Use restaurant.customReservationList',
  })

[MichalLytek]

In V2 generally or the last beta 4.

[tgomesfork]

The issue was already there in 2.0.0-beta.2

[MichalLytek]

@tgomesfork I've checked and it's stored properly in memory of build schema and introspection results.
So this only affect the printed schema, which might be a change in graphql-js itself.
If you could reproduce this with using raw new GraphQLObjectType and different graphql-js version, please report on their repo.