Fix for Issue #39 Broke Optional Types in General

[schettn]

Original Issue Reference

Issue #39 introduced a fix to allow default values for parameters in GraphQL resolver functions. However, this fix has inadvertently broken the handling of optional parameters in general.

Problem Description

The current implementation does not support optional parameters (foo?: string or foo: string | undefined) in resolver functions due to the changes made in the fix for Issue #39. While the fix correctly handles parameters with default values, it has caused a regression for optional parameters.

Examples

Required (Working):

export const graphql = {
  Query: {
    test: (foo: string) => {
      return foo;
    }
  }
}

Optional (Not Working):

export const graphql = {
  Query: {
    // or foo: string | undefined
    test: (foo?: string) => {
      return foo;
    }
  }
}

Default Value (Working):

export const graphql = {
  Query: {
    test: (foo: string = 'bar') => {
      return foo;
    }
  }
}

Steps to Reproduce

1. Define a GraphQL resolver with an optional parameter (foo?: string or foo: string | undefined).
2. Attempt to query using this resolver with and without providing the optional parameter.

Expected Behavior

The resolver functions should handle optional parameters correctly, returning the appropriate values based on whether the parameter is provided or not.

Actual Behavior

The resolver functions fail to handle optional parameters, leading to runtime errors or incorrect behavior.

Impact

This issue prevents the use of optional parameters in resolver functions, reducing the flexibility and usability of the GraphQL API.

Additional Information

Please refer to the original issue for context: Issue #39.

[github-actions]

🎉 This issue has been resolved in version @getcronit/pylon-builder-v2.4.1 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀