Fields default values ignored after migrating from Babel to SWC

[fromi]

I use typegraphql in a Next.js project. I am trying to move from Babel to SWC to reduce compile time, and everything works fine except for one thing: typegraphql used to return my default field value with babel when it was undefined in my return statement, and now with SWC, it remains undefined (leading to "cannot return null for non-nullable field" errors).

Here is an example:

@ObjectType()
export class GameOptions {
  @Field(() => Int)
  maxSpareTime = MAX_SPARE_TIME

When I return a GameOptions objet without this field (not very clean, but it comes from mongoose directly), with Babel, TypeGraphQL was automatically returning MAX_SPARE_TIME. With SWC, it does not.

Here is my Babel configuration:

{
  "presets": [
    "next/babel"
  ],
  "plugins": [
    "babel-plugin-transform-typescript-metadata", [
      "@babel/plugin-transform-typescript", {
        "allowDeclareFields": true
      }
    ], [
      "@babel/plugin-proposal-decorators", {
        "legacy": true
      }
    ], [
      "@babel/plugin-proposal-class-properties", {
        "loose": true
      }
    ]
  ]
}

Do you know why the default class structure was used with Babel, and why it is now used with SWC?
Is there simple way to get property fallback with TypeGraphQL? @Field({default: ...}) does not work for return types. I can do custom resolvers, but it is a but messy of course. The best solution would be a way to configure SWC to have the same behavior as I use to have with Babel of course, to prevent unexpected regressions...

[MichalLytek]

TypeGraphQL uses a trick to detect default values. It creates a new instance of the class and then reads the instance's property value.
I have no experience to tell what settings SWC needs but in the meantime you can use { defaultValue } workaround.

[MichalLytek]

https://github.com/carlocorradini/type-graphql/blob/master/src/helpers/types.ts#L87-L110

[MichalLytek]

this is the code used for output types like object type

[MichalLytek]

but it's not used to transform value {} from returned from resolver, only to parse it as @Root() in field resolvers

[MichalLytek]

in other words, please create a @FieldResolver() and return there the default value or root.foobar if defined or new api or something else

[fromi]

Ok, thanks! So, the fact that it worked with Babel was probably some sort of side effect.
I already created a FieldResolver for the most problematic point in our API, the rest was just made nullable to make it work.
It is a bit sad though, having to create a FieldResolver to create a fallback for undefined values is way more verbose.

Thank you for your help