[feat]: Autogenerated TypeScript types?

[jgb-solutions]

A clear and concise description of what the feature is

Strapi is very popular and it was time for it to have a SDK. I just tried it and it works but with no types, it's not very appealing to modern projects using TypeScript. I know I could use GraphQL but that's another big mental hurdle of its own.

Why should this feature be included?

Autogenerated TypeScript types from the API.

Please provide an example for how this would work

In modern frontend for web and mobile apps using TypeScript.

[innerdvations]

That feature is on its way! We're currently testing a few different options for generating the types to find what works best, and are hoping to implement it in the coming weeks.

And thanks for your interest, it's great to see people already trying out the SDK.

[hanpaine]

Hey @jgb-solutions thanks for your interest! This is just the beginning for our SDK. The full roadmap can be seen here: https://www.notion.so/strapi/Strapi-JavaScript-SDK-plan-15f8f35980748046b7f8fb207b29c64b

[jgb-solutions]

Hey @hanpaine @innerdvations thanks guys for replying quickly. I was looking for this for a while and I've been using Strapi for a many years now. I stepped away a little bit because of the bad DX of fetching data. I'll keep looking for new releases of this package. Good job guys!

[Convly]

Hey @jgb-solutions, I just wanted to keep you updated on this as you've expressed some interest on the subject 🙂

We've actually started the research and development for the generation of better types and APIs for the SDK. The research itself took quite some time but we're confident we're heading in the right direction and will soon be able to start the development.

We'll update you when we have more news to share about our progress!

Have a great day 🎉

[jgb-solutions]

Hey @jgb-solutions, I just wanted to keep you updated on this as you've expressed some interest on the subject 🙂

We've actually started the research and development for the generation of better types and APIs for the SDK. The research itself took quite some time but we're confident we're heading in the right direction and will soon be able to start the development.

We'll update you when we have more news to share about our progress!

Have a great day 🎉

Thank you for the update @Convly. I appreciate it.

[fsbtmo]

Hi! Exciting news that your are actively developing this feature!

We currently use the Documentation plugin to generate types and api for our frontend. Some things come to mind, which currently don't work well:

• almost all fields are nullable, so the "required" set in strapi is often ignored
• no types for the RichText field
• relations are not typed (only the properties id and documentId are inside a relation field -> would be nice to get a reference to the selected relation type of the field)

We are looking forward to try this out!

[Convly]

Hey @fsbtmo, thanks for your feedback, we're actively working on this at the moment and we'll take that into account!

FYI: it requires quite a bit of work on both Strapi and client side, so we don't have an exact timeline yet

[Dovakeidy]

@innerdvations @hanpaine @Convly

Hi! I've created a wrapper around the Strapi client to add type support in a monorepo environment. Once this is set up, you'll have full type support for the collections defined in your Strapi project.

It was put together in just a few hours, so there's definitely room for improvement — but I think it could still be helpful to some people.

The idea was to re-use the TypeScript types generated by Strapi within the monorepo (with tsconfig.json include field), making them available throughout the project. Since it uses the import type feature, all type-only imports from @strapi/types will be stripped out during production transpilation, so it’s not a big deal.

[Convly]

Hey @Dovakeidy, nicely done, love to see things like that!

To give some insights: we're focusing on generating a fully typed programmatic API that mirrors your REST API at the moment and haven't dived into typing the CT and ST managers yet, your solution is a good start for non-customized endpoint though!

The thing I would change at first glance (and where it's possible) are the types’ imports to use the exported root namespaces so that it doesn't break if we change the internals.

If you want to share your workaround with other developers, you can open a pull request for the client's readme explaining how to enable this while waiting for a more "official" solution to come. What do you think?

Note: I haven't dived too much into the code itself yet, but I can provide a review if you decide to open a PR

[Dovakeidy]

@Convly

If you want to share your workaround with other developers, you can open a pull request for the client's readme explaining how to enable this while waiting for a more "official" solution to come. What do you think?

Thanks for the answer! Should the README include the full solution, or just a link to a Gist, discussion, or issue?

Regarding the types, I've improved the solution, but two exports are missing from the client: ClientCollectionOptions and SingleCollectionOptions.
Can we export them in export.d.ts?

EDIT: I've included a new option (wrappedByKey) in the typed client that could also be useful in the original client.
What do you think?

It was inspired by the Astro Strapi integration example.
This option is particularly useful in SSG environments, where you might not care about pagination and want to reduce the API payload, since the call is only made once.