Type error when using the third parameter for `define<...>`

[TomiHiltunen]

Hi! 👋

I'm facing a type error when I define the third parameter to be used upon using .create(). My first type, Prisma.OrganizationCreateInput, is a Prisma generated input payload type. It has two required properties: slug, and name. The third parameter, Organization, is as well a Prisma generated type. This is the type used for successfully created (or fetched) entities. In addition to the mandatory fields in Prisma.OrganizationCreateInput, Organization also contains the property id as required. I can't quite understand why I'm getting this type error when it seems that my setup is pretty much exactly like in the examples.

Any tips would be appreciated!

I'm using fishery@1.4.0.

---

Code:

import { Factory } from 'fishery';
import faker from 'faker';
import db from '../lib/db';
import { Prisma, Organization } from '@prisma/client';

export default Factory.define<
  Prisma.OrganizationCreateInput,
  any,
  Organization
>(({ onCreate }) => {
  onCreate((organization) => db.organization.create({ data: organization }));

  const organizationName = faker.company.companyName();

  return {
    name: organizationName,
    slug: faker.helpers.slugify(organizationName),
  };
});

---

Error:

The 'this' context of type 'typeof Factory' is not assignable to method's 'this' of type 'new (generator: GeneratorFn<OrganizationCreateInput, any>) => Organization'.
  Types of construct signatures are incompatible.
    Type 'new <T, I = any>(generator: (opts: GeneratorFnOptions<T, I>) => T) => Factory<T, I>' is not assignable to type 'new (generator: GeneratorFn<OrganizationCreateInput, any>) => Organization'.
      Type 'Factory<OrganizationCreateInput, any>' is missing the following properties from type 'Organization': name, slug

[stevehanson]

@TomiHiltunen thanks for opening this issue. This feature had not yet made it into a build. I went ahead and just published v2.0.0 with this feature (major version bump due to the different behavior with afterCreate vs. onCreate).

I'll go ahead and close this but let me know if you still have issues.

[TomiHiltunen]

@TomiHiltunen thanks for opening this issue. This feature had not yet made it into a build. I went ahead and just published v2.0.0 with this feature (major version bump due to the different behavior with afterCreate vs. onCreate).

@stevehanson, I've updated the package version on my end to 2.0.0 and it's working smoothly now. Thanks!