support new configuration option moduleNamingMode

[HunterLarco]

TL;DR

Prior to this change, schema files had to be flattened within modules; otherwise, this plugin would break. This update introduces a new option, moduleNamingMode, that allows for deeply nested schema files. The change is backward compatible with existing workflows.

Background

When parsing GraphQL schema files, the plugin identifies the "module name" for each schema file. It currently determines the module name by taking the parent directory of each schema file. This approach works well when the last folder denotes the module name, as seen in nested-domain-modules.

Problem

The current behavior causes issues when a project organizes schema files within additional subfolders inside a module. For example, our project structure looks like this:

codegen.ts
modules/
  user/
    schema/
      User.graphql
  profile/
    schema/
      Profile.graphql
      User.graphql

We configure codegen.ts to generate a resolvers/ directory in each module because we value separating implementation from API definitions. However, this setup breaks the plugin. In the example above, the module name for both profile/schema/User.graphql and user/schema/User.graphql is incorrectly identified as schema. This happens because the plugin takes the parent directory (schema) as the module name.

As a result, the definitions are merged under the same module name schema, and User resolvers are only generated for one of the modules—depending on the order in which the files are processed—leading to unpredictable behavior.

Solution

To address this issue, I've added a new option moduleNamingMode that allows clients to specify how the module name is determined:

• last (default): The module name is the last folder in a file's path (existing behavior).
• first: The module name is the first folder (within the working directory) in a file's path.

Using first means that if codegen is pointed to /path/to/modules, the module names will be the first layer of folders within /path/to/modules (e.g., user and profile). This allows for deeper nesting within modules without breaking the plugin.

Please refer to the e2e test included in this PR for an example of how this works in practice.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 8b0af6b

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR