Generate TypeScript types and interfaces

[bvobart]

Hi Pipedrive team! As I understand, this Pipedrive client library has been generated based on the OpenAPI specification since v11. Is it possible for the client generator to also generate TypeScript types / interfaces for the client?

That would make it much easier to use this library in a type-safe way in TypeScript projects. Even in plain JavaScript projects, the IDE would feature better support and recommendations for working with this library. I'm not sure what generator you're using, but this seems like a relatively low effort high reward solution.

[bvobart]

I see you are using https://github.com/openapitools/openapi-generator, which according to their ReadMe has support for generating TypeScript NodeJS clients :)

[bvobart]

I experimented with running openapi-generator-cli generate -i https://developers.pipedrive.com/docs/api/v1/openapi.yaml --generator-name typescript-node -o . to see if I could generate a TypeScript version of this Pipedrive client myself, but I'm getting a whole bunch of [main] WARN o.o.codegen.DefaultCodegen - Unknown type found in the schema: object warnings, and some unresolvable base types.

I don't know how you generate the code in this repository, as you have not open-sourced the generator code as far as I could find, so I can't help you (or myself) there very much.

But the idea is pretty simple:

• Configure openapi-generator to use one of their TypeScript targets, whichever fits you best.
• Create a tsconfig.json file (tip: check @tsconfig packages for a stable base)
• Add tsc to your package.json's build command.
• Reconsider the Babel configuration, some of the things Babel does might not be necessary anymore as TypeScript can do them too.

[hemchander23]

Hey @bvobart! Thanks for sharing the relevant details. Highly appreciate that :)

Tagging our SDK expert @RuTsEST to bring more visibility.

[SpaceOven]

Hi guys! TypeScript is in the plans, but not for the near future. Proper testing needs to be done and it will certainly need some adjustments before a release. Stay tuned!

[bvobart]

@SpaceOven @RuTsEST Thanks for your answer! I understand that it is difficult to pin down a particular date, but can you give a more concrete indication as to when "in the plans, but not for the near future" will be?

Also, this issue is not yet resolved as no TypeScript support has been implemented yet, so may I ask why you closed this issue? It'd be very useful for all of us waiting for TypeScript support to see this issue in the open issues list and be kept up to date here about the progress (or lack of progress) on this issue.

As a final note (perhaps a bit off-topic): in this repo you have open-sourced the NodeJS Pipedrive API client implementation, but since this is a generated client, pull requests to this repo from contributors are practically useless. I've seen a few PRs being shot down with a comment like 'thanks for the contribution, but we have to update it in our generator code' That generator code, however, is not open-sourced afaik, so there is no way for contributors to aid in fixing small bugs or experimenting with proper TypeScript support. What are your thoughts on this? And have you considered open-sourcing the generator code?

[sibelius]

I think this issue should be kept open

typescript is the minimal to provide a good dx

[RuTsEST]

Hey @bvobart, @sibelius!

Thanks for your interest in the SDK! Unfortunately I'm not in position to say when we're going to implement the typescript version of the SDK. Maybe @HappyVlad can give more concrete estimates?

The project itself could be quite big as well with quite a few unknowns:

• making the underlying YAML files compatible with the TS generator (there are hundreds of them and this is probably the biggest time sink)
• making sure it has dual auth support (OAuth and api-token) and implementing it if needed
• supporting multiple instances for different users and different apps Feature request: Support change of redirect URI with api or allow multiple #318.

Maybe releasing the alpha/beta version of the typescript SDK with the underlying generator would be the best course of action since we could start working on it iteratively?

I do also agree that in order to let 3rd party developers contribute more efficiently to our SDKs, the underlying generators could be made open source but the security guys might require prior work to make it publishable. Also it's not that difficult to copy over the JS changes to the templates so PRs with JS changes and improvements are still useful for us though I agree it's not perfect.

[JeremySazMining]

bump .. this is 2022 n this is a paid product

[markstreich]

⚠️ this doesn't support (at least) different response status codes, but in case it's helpful to someone:

I generated types with https://developers.pipedrive.com/docs/api/v1/openapi.yaml

npx openapi-typescript openapi.yaml --output pipedrive.ts

.. then I deleted exports from that file and made it a .d.ts, and added a declaration at the top (I'm just using ApiClient + DealsApi.getDeals but should be obvious how to add other methods)

pipedrive.d.ts: https://gist.github.com/markstreich/656c17e737d504f2c530faab697342d4

which gives me what I wanted (some helpful vscode typehints):

[WMRamadan]

Hey @RuTsEST & @HappyVlad

Is it possible to start a branch for the TypeScript conversion in this repo and have it overlooked by the PipeDrive team?

I noticed you mentioned "The underlying generators could be made open source but the security guys might require prior work to make it publishable" so how long would you estimate that something like this would take?

[rdylina]

I agree with all previous statements. This is long overdue for a platform like pipedrive. If you're not prepared to commit the resources then just publish the base generator code and let the community contribute.

[jeanhdev]

I'd really like it typed too ! Thank you :))

[ibraelillo]

I've managed to create the client by creating the API in swagger hub, then exporting a typescript client based on the openapi doc file.

[maddsua]

To be honest, I don't event get why would anyone use the client in it's current state. Types would be the only reason for me, otherwise it isn't better than using REST API directly.

Don't get me wrong, but actually what's the point? All it does is formats search queries for you. Not super useful considering the package's size

[maddsua]

Heey, anyone willing to rewrite the entire client fully in TS? I got to the point where I kinda done it anyway, but it's not a full client yet, just the API's that I use

[jpike88]

super disappointing. feels like I'm using a library stuck 10 years in the past. will use my own REST client instead.

[sammychurchill]

Didn't use this lib because of no types. What is the point of maintaining this if the best part would be types

[jpike88]

for those looking for an easy alternative, axios is best:

const result: {
			data: {
				success: boolean;
				data: {
					id: number;
				};
			};
		} = await axios.post(
			`https://api.pipedrive.com/v1/organizations?api_token=${apiKey}`,
			{
				name: 'bla bla',
				address: 'etc whatever',
			},
			{
				timeout: 5000,
				headers: {
					'Content-Type': 'application/json',
					Accept: 'application/json',
				},
			}
		);


		if (result?.data?.success) {
		  // do stuff
		}

[y-nk]

@martintajur @RuTsEST @HappyVlad are there any plans to cover this part?

[prescience-data]

I started building out a generation script that consumes the openapi spec json and generates Zod schemas and types for validation, but I ran out of time on the project and had to just implement the parts of the API we use manually.

But it's very possible if the Pipedrive team have the inclination with libraries like https://github.com/astahmer/openapi-zod-client which allow e2e typesafety and runtime validation.

[julestruong]

Really ? this as opened nearly 2 years ago and nothing :(

[y-nk]

We can assume Pipedrive don't care much about DX as long as we get along. Until there will be enough support tickets on their CX platform written "We want types" they won't prioritize it.

Best action for all here is to file a customer support request and ask for types. Together we may have a chance.

[santanaluiz]

wow.... this is still not done.

Is this a joke?

[ptrtht]

bump, its 2024 now guys, for a paid product.

What is the point of using this library if there are no types? You wrote the fetch requests for me? Thx :)

[l0rem]

2024 no types let's goo!

[maddsua]

Welp...
[removes pipedrive from the list of recommended CRMs]
...done ✅

[y-nk]

for people interested, it's 2024 so you can do this: https://chat.openai.com/c/0f354986-599a-4a22-a86f-770e23f66f52

[youssef-saber-3]

Hey everyone, sorry for the delay in implementing this, we've released a beta version of the typescript sdk , you can follow the guide here for setup and feel free to give feedback or report any issues you run into

[jekuno]

@youssef-saber-3 Thanks for that first typed version. I had a look at it and want to give you some feedback, as you asked for.

There still seems to be some manual work to do, e.g. the interface names generated by Openapi Generator are quite lengthy and sometimes misleading as well.

Example: The interface GetOrganizationsResponse200AllOf (GetOrganisations!) has an additional_data property of type GetActivitiesResponse200AdditionalData (GetActivities!). It would be shorter and prevent confusion to name it AdditionalData instead, as it's a generic interface and doesn't have any specific data related to activities or organizations.

Also, a type which only holds some generic pagination information, should have a compact and generic name as well, such as PaginationDetails, instead of GetActivitiesResponse200AdditionalDataPagination. And its boolean property more_items_in_collection should be a strict boolean instead of boolean | undefined. Also start and limit should be required numbers instead of optional numbers in a pagination type.

@youssef-saber-3 Do you already have a roadmap on how to proceed towards a stable typed release? Thanks again for your work!

[jono-allen]

@youssef-saber-3 Thankyou for the work on getting typescript support for pipe drive.
We have attempted to set pipedrive 22.3.1-rc.3 in a monorepo (Via SST) https://sst.dev/ using yarn classic.

When we execute the lambda, we get the following error

   Could not resolve "../package.json"
   ../../node_modules/pipedrive/dist/esm/base.js
   30 │     const version = require("../package.json").version;
   Could not resolve "../package.json"
   ../../node_modules/pipedrive/dist/esm/configuration.js

Thanks

[youssef-saber-3]

@youssef-saber-3 Thanks for that first typed version. I had a look at it and want to give you some feedback, as you asked for.

There still seems to be some manual work to do, e.g. the interface names generated by Openapi Generator are quite lengthy and sometimes misleading as well.

Example: The interface GetOrganizationsResponse200AllOf (GetOrganisations!) has an additional_data property of type GetActivitiesResponse200AdditionalData (GetActivities!). It would be shorter and prevent confusion to name it AdditionalData instead, as it's a generic interface and doesn't have any specific data related to activities or organizations.

Also, a type which only holds some generic pagination information, should have a compact and generic name as well, such as PaginationDetails, instead of GetActivitiesResponse200AdditionalDataPagination. And its boolean property more_items_in_collection should be a strict boolean instead of boolean | undefined. Also start and limit should be required numbers instead of optional numbers in a pagination type.

@youssef-saber-3 Do you already have a roadmap on how to proceed towards a stable typed release? Thanks again for your work!

Hey , thank you for the feedback, it's much appreciated !, i agree regarding the interface names , it will be better if they were shorter and more descriptive, we'll look into ways of improving that.
our plan is to take the feedback developers give and do internal testing ourselves to fix the issues that come up before doing a major stable release

[mjhagen]

May I suggest calling this an alpha release then? A beta typically doesn't change all that much with regard to naming things.

[youssef-saber-3]

May I suggest calling this an alpha release then? A beta typically doesn't change all that much with regard to naming things.

yeah, that makes sense

[youssef-saber-3]

@youssef-saber-3 Thankyou for the work on getting typescript support for pipe drive. We have attempted to set pipedrive 22.3.1-rc.3 in a monorepo (Via SST) https://sst.dev/ using yarn classic.

When we execute the lambda, we get the following error

   Could not resolve "../package.json"
   ../../node_modules/pipedrive/dist/esm/base.js
   30 │     const version = require("../package.json").version;
   Could not resolve "../package.json"
   ../../node_modules/pipedrive/dist/esm/configuration.js

Thanks

Hey, we looked into this and the issue you're facing should be fixed in this version 22.3.1-rc.4

[ljrodriguez1]

How is this going?

[zero1zero]

@youssef-saber-3 Thankyou for the work on getting typescript support for pipe drive. We have attempted to set pipedrive 22.3.1-rc.3 in a monorepo (Via SST) https://sst.dev/ using yarn classic.
When we execute the lambda, we get the following error

   Could not resolve "../package.json"
   ../../node_modules/pipedrive/dist/esm/base.js
   30 │     const version = require("../package.json").version;
   Could not resolve "../package.json"
   ../../node_modules/pipedrive/dist/esm/configuration.js

Thanks

Hey, we looked into this and the issue you're facing should be fixed in this version 22.3.1-rc.4

I'm still running into this issue with 22.3.1-rc.5

[youssef-saber-3]

How is this going?

Hey , we're currently in the process of standardising how types are named to keep it consistent between different api resources and between the php and typescript sdk. unfortunatley this has taken a bit more time but we should have an update soon