How do I have Counterfact use component types generated by another source?

[dethell]

The docs suggest that CF does not have to generate the component types. One of our projects already generates the types from the openapi spec and we would like CF to import those types instead of generating the schema components. Of course, CF would then need to use those imports in all its types and paths.

[dethell]

Bump. Any thoughts on this one? I haven't dug into the code, but I'm hoping for a way to skip the component generation and import from the outside.

[pmcelhaney]

Sorry, I haven't been paying attention to discussions and missed this. Counterfact generates types for components but not classes.

Using the petstore as an example, it generates this type for Pet.

import type { Category } from "./Category.js";
import type { Tag } from "./Tag.js";

export type Pet = {
  id?: number;
  name: string;
  category?: Category;
  photoUrls: Array<string>;
  tags?: Array<Tag>;
  status?: "available" | "pending" | "sold";
};

I've been thinking it may be useful to also generate components. They might look something like this:

import { Pet as IPet } from "../types/components/Pet.js"; 

export class Pet implements IPet {
  id?: number;
  name: string;
  category?: Category;
  photoUrls: Array<string>;
  tags?: Array<Tag>;
  status?: "available" | "pending" | "sold";

  constructor(pet: IPet) {
    this.id = pet.id;
    this.name = pet.name
    this.category = pet.category;
    this.photoUrls = pet.photoUrls;
    this.tags = pet.tags;
    this.status = pet.status;
  }
}

Why two different files? Because the type is kept in sync with OpenAPI. The class file would be treated the same way as routes. Counterfact creates the file. Then you can augment it without worrying that your changes will be overwritten.

What do you think? Would that be helpful?

[pmcelhaney]

If another tool generates classes, you should be able to use them as long as the classes fit the types generated by Counterfact. Some concepts from JSON Schema don't map directly to TypeScript so there's room for interpretation.

What tool are you using to generate classes?

[dethell]

Not sure I follow. Do you mean having Counterfact output the files in the other project/package like this?:

npx counterfact some-spec.yml ../../projects/other-project/api

[pmcelhaney]

Yes. I guess the question is why isn't the spec file in the same package?

[dethell]

The primary reason is, we separate our generated API code into an api project and our mock server into a mock-server project. Since Counterfact is primarily responsible for running the mock server, we felt like it didn't separate responsibilities enough for either the generated API code to live inside of a project called mock-server or for the mock-server project to output the generated code to another project. Trying to separate the boundaries a bit.

That said, we think it's fine to add Counterfact as a devDependecy to the api project and just alter our generate script to use CF instead of swagger-typescript-api. But then we still have the problem of how to tell the mock-server where to import its types.

[pmcelhaney]

Maybe it would make sense to run Counterfact from the project where you're putting types? The package that contains the spec file could be a dependency of the package that contains types and you would reference it via node-modules/@org/whatever/openapi-spec.yaml

[dethell]

Yeah, I've considered just dropping the idea of a separate mock-server project and instead just have the mock server be spun up as part of the api project since in a sense mocks are part of testing the API.