Generate TypeScript types and interfaces

bvobart commented 2 years ago

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 commented 2 years ago

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

bvobart commented 2 years ago

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 commented 2 years ago

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

Tagging our SDK expert @RuTsEST to bring more visibility.

SpaceOven commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

I think this issue should be kept open

typescript is the minimal to provide a good dx

RuTsEST commented 2 years ago

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 https://github.com/pipedrive/client-nodejs/issues/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 commented 2 years ago

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

markstreich commented 2 years ago

⚠️ 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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

ibraelillo commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

sammychurchill commented 1 year ago

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

jpike88 commented 1 year ago

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 commented 1 year ago

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

prescience-data commented 1 year ago

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 commented 11 months ago

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

y-nk commented 11 months ago

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 commented 11 months ago

wow.... this is still not done.

Is this a joke?

ptrtht commented 10 months ago

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 commented 10 months ago

2024 no types let's goo!

maddsua commented 10 months ago

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

y-nk commented 10 months ago

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

youssef-saber-3 commented 10 months ago

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 commented 10 months ago

@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 commented 10 months ago

@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 commented 10 months ago

@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 commented 10 months ago

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 commented 10 months ago

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 commented 9 months ago

@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 commented 7 months ago

How is this going?

zero1zero commented 6 months ago

@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 commented 6 months ago

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

s-pogoda commented 4 months ago

Hi @zero1zero, we published 23.0.0-rc.2 last week that includes the latest updates to the Pipedrive API, and issue with getting version should be fixed too

youssef-saber-3 commented 2 months ago

Hey , we've pubilshed a new version with improved interface names 23.2.5-rc.2 , we've made the interface names more consistent but there might be still some long interface names due to limitations with auto generating the sdk, feel free to leave any feedback you have

youssef-saber-3 commented 3 days ago

Hey , we've published a new version 23.3.0-rc.4 with some fixes for the issue where typescript throwing an error if you try to use a custom field hash in PUT endpoints for deals , persons , orgs and products. as well as fixing an issue with optional keys in some interfaces

pipedrive / client-nodejs

Generate TypeScript types and interfaces #340