JSDoc are ignored

Bug description

JSDoc are ignored and not processed in schema output. I couldn’t investigate why this happens but it appears that parsed jsDoc array is always empty at this line. The parser doesn’t recognize other JSDoc (@type) at this point.

The library runs programmatically:

  generate({
      sourceText: data,
      keepComments: true,
    });

Same for CLI, with and without keepComments option.

Input

The same example as in documentation:

export interface HeroContact {
  /**
   * The email of the hero.
   *
   * @format email
   */
  email: string;

  /**
   * The name of the hero.
   *
   * @minLength 2
   * @maxLength 50
   */
  name: string;

  /**
   * The phone number of the hero.
   *
   * @pattern ^([+]?d{1,2}[-s]?|)d{3}[-s]?d{3}[-s]?d{4}$
   */
  phoneNumber: string;

  /**
   * Does the hero has super power?
   *
   * @default true
   */
  hasSuperPower?: boolean;

  /**
   * The age of the hero
   *
   * @minimum 0
   * @maximum 500
   */
  age: number;
}

Expected output

Should be same as in docs:

export const heroContactSchema = z.object({
  /**
   * The email of the hero.
   *
   * @format email
   */
  email: z.string().email(),

  /**
   * The name of the hero.
   *
   * @minLength 2
   * @maxLength 50
   */
  name: z.string().min(2).max(50),

  /**
   * The phone number of the hero.
   *
   * @pattern ^([+]?d{1,2}[-s]?|)d{3}[-s]?d{3}[-s]?d{4}$
   */
  phoneNumber: z.string().regex(/^([+]?d{1,2}[-s]?|)d{3}[-s]?d{3}[-s]?d{4}$/),

  /**
   * Does the hero has super power?
   *
   * @default true
   */
  hasSuperPower: z.boolean().default(true),

  /**
   * The age of the hero
   *
   * @minimum 0
   * @maximum 500
   */
  age: z.number().min(0).max(500),
});

Actual output

JSDocs are ignored in schema output:

export const heroContactSchema = z.object({
    /**
     * The email of the hero.
     *
     * @format email
     */
    email: z.string(),
    /**
     * The name of the hero.
     *
     * @minLength 2
     * @maxLength 50
     */
    name: z.string(),
    /**
     * The phone number of the hero.
     *
     * @pattern ^([+]?d{1,2}[-s]?|)d{3}[-s]?d{3}[-s]?d{4}$
     */
    phoneNumber: z.string(),
    /**
     * Does the hero has super power?
     *
     * @default true
     */
    hasSuperPower: z.boolean(),
    /**
     * The age of the hero
     *
     * @minimum 0
     * @maximum 500
     */
    age: z.number()
});

Intermediate type output contains no changes, only indentation:

export interface HeroContact {
    /**
     * The email of the hero.
     *
     * @format email
     */
    email: string;
    /**
     * The name of the hero.
     *
     * @minLength 2
     * @maxLength 50
     */
    name: string;
    /**
     * The phone number of the hero.
     *
     * @pattern ^([+]?d{1,2}[-s]?|)d{3}[-s]?d{3}[-s]?d{4}$
     */
    phoneNumber: string;
    /**
     * Does the hero has super power?
     *
     * @default true
     */
    hasSuperPower: boolean;
    /**
     * The age of the hero
     *
     * @minimum 0
     * @maximum 500
     */
    age: number;
}

Versions

• node v14.17.3
• ts-to-zod: v1.5.2
• Typescript: v4.2.3 (ts-to-zod own dependency)
• Zod: v3.11.2 (ts-to-zod own dependency)

[bisubus]

I ended up with the fix on my side:

  "devDependencies": {
    "tsutils": "1.0.0",
  },
  "resolutions": {
    "ts-to-zod/typescript": "4.2.3",
    "ts-to-zod/tsutils/typescript": "4.2.3"
  },

a) provide level 1 dummy tsutils dep that prevents tsutils@3.21.0 from being hoisted from nested deps

b) force typescript@4.2.3 for ts-to-zod because tsutils@3.21.0 somehow installed typescript@4.4.3 at ts-to-zod/node_modules/tsutils/node_modules/typescript , likely because of its loose peer dependency on typescript, although the reasoning for this never came up, probably a quirk of Yarn

I’m not sure whether this can be fixed on package level. Probably by informing users of possible implications if they install it locally together with other TS libs. I’m aware of hoisting problem, but this is the first time it messed up things for me in a very obscure way.

[fabien0102]

@bisubus Thanks for this amazing debugging!

Indeed, when I run your repro repo with npm instead of yarn, this is working as expected:

I’m also not sure how to fix this at the package level 😕 I will try to see what I can do to at least warn the user.

Thanks again for reporting & debugging this! 🎉