TS - Generated types are a bit off.

[antokhio]

Bug report

Required System information

• Node.js version: 18.18.1
• NPM version:
• Strapi version: 4.17.1
• Database: SQLite
• Operating system: Windows
• Is your project Javascript or Typescript: Typescript

Describe the bug

Hi, first, i'm really enjoying the generate-types feature, however would like to highlight few issues with end typings:

So, first of, the default value in database is always null:

export type SharedLink = Attribute.GetValue<Attribute.Component<'shared.link', false>>;
// Gives:
type SharedLink = {
    id: ID;
} & {} & {
    title?: string;
    href?: string;
}

// Noramllally if i do this by hand, i do it like this:
export type StrapiComponent<T = any> = {
  id?: number;
} & {
  [P in keyof T]: T[P];
};

export type SharedLink = StrapiComponent<{
  title: string | null;
  href: string | null;
}>;

export type Layout = StrapiContentType<{
  tel?: SharedLink | null;
]>;

so the issue is strings (as many other values, such as populated components) are defaults to null, and are not undefined unless explicitly removed with select or fields

this is going to introduce issues with optional initial values like:

const { myString = 'default' } = props; 
// this only works if myString is undefined but it's null

Second. Not sure if that's how content-type should work:

export type Layout = Attribute.GetValues<'api::layout.layout', Attribute.GetKeys<'api::layout.layout'>>;

Third. The mediaType:

export type SharedImage = Attribute.GetValue<Attribute.Component<'shared.image', false>>;
type SharedImage = {
    id: ID;
} & {} & {
    image?: any;
    title?: string;
}

Fourth. Currently you need to have /src/types/generated in every project you are going to use types.
This brings quite a complexity:

packages: 
   backend   << generates types
   frontend  << should get types updated
   shared << should get types updated

Code snippets

export type StrapiMedia = {
  id: number;
  name: string;
  alternativeText: string | null;
  caption: string | null;
  width: number | null;
  height: number | null;
  formats?: StrapiMediaFormats | null;
  hash: string;
  ext: string;
  mime: string;
  size: number;
  url: string;
  previewUrl: string | null;
  provider: string;
  provider_metadata: null | string;
  createdAt: string;
  updatedAt: string;
};

export type StrapiMediaFormats = {
  large?: StrapiMediaFormat;
  small?: StrapiMediaFormat;
  medium?: StrapiMediaFormat;
  thumbnail?: StrapiMediaFormat;
};

export type StrapiMediaFormat = {
  ext: string;
  url: string;
  hash: string;
  mime: string;
  name: string;
  path: string | null;
  size: number;
  width: number;
  height: number;
};

https://gist.github.com/antokhio/585b391bf034e2ce194ad32e44d34260
here is full code of strapi types i've been using before this feature.

Additional context

Add any other context about the problem here.

[antokhio]

New WIP findings:

type Modify<T, R> = Omit<T, keyof R> & R;

/**
 * @param {T} T Strapi content type Uid
 * @param {U} U Schema overrides
 */
export type StrapiContentType<T extends Common.UID.Schema, U extends object = {}> = Modify<
  Attribute.GetValues<T, Attribute.GetKeys<T>>,
  U
>;

/**
 * @param {T} T Strapi component Uid
 * @param {U} U Schema overrides
 * @param {R} R Repatable, should be `false` - has issues
 */
export type StrapiComponent<
  T extends Common.UID.Component,
  U extends object = {},
  R extends Attribute.BooleanValue = false,
> = Modify<Attribute.GetValue<Attribute.Component<T, R>>, U>;

[Convly]

Hi there, thanks a lot for opening this issue.

I haven't answered before because I was in the process of reviewing the entire type system to list every change we want to make (especially the breaking ones) before the V5 release.

As of today, required fields represent application logic and not DB logic. This is why you can even end up with a required field with a "null" value. (e.g. with a draft entry, you can save without setting the required fields, but you have to fill them before publishing the entry).
However you're right, we should transpose this to the types, and values should be typed accordingly. We're going to take that into account with the upcoming changes 🙂

export type Layout = Attribute.GetValues<'api::layout.layout', Attribute.GetKeys<'api::layout.layout'>>;

Here, the second parameter is optional and should default to the same thing, but otherwise, yes that's the idea.
In V5, we will introduce the concepts of documents and entities, so that you can type you entry using something much clearer such as: Document.Document<'api::layout.layout'>.
I'm also exploring additional options such as exposing generated types aliases like Documents.ApiLayoutLayout or Documents.API.Layout.Layout. (Still in discussion, might be added in a later step after V5 release, depending on users feedback)

Third. The mediaType:

Yep, this one needs better types indeed

Fourth. Currently you need to have /src/types/generated in every project you are going to use types.
This brings quite a complexity:

If you're in a monorepo, you could reference the directory from other projects' tsconfig.json
One thing we could add is project configuration to specify where to export the auto-generated types 🤔
Maybe something like { out: <dir> } in ./config/typescript.[js|ts].
Anyway, it's indeed a bit tedious, we'll work on improving this

* @param {R} R Repatable, should be false - has issues

What issue do you have here?

[antokhio]

@Convly thx for replay, i must admit so far so good. :)

So:

• @param {R} R Repatable, should be false - has issues

This issue with my Modify type

type Modify<T, R> = Omit<T, keyof R> & R;

When component is repeatable, the Modify breaks. And since i use StrapiComponent or StrapiContentType i'm not really using Repeatable anyways. Like normally i do:

export type HomePageHero = StrapiComponent<'home.hero', { image?: StrapiMedia | null }>;

interface HomeHeroProps extends Partial<HomePageHero> {}

const HomeHero = ({ title, description, image, link }: HomeHeroProps): JSX.Element => {...}

const Home = (): JSX.Element => {
  const { seo,  hero } = useHomePage();
  return (
    <Layout seo={seo}>
      <HomeHero {...hero} />
    </Layout>
    );
 };

So, issues with monorepos:

The first one, is frontend needs @strapi/strapi as devDependencies, witch is kinda doggy:

My package.json for next looks like this:

{
  "name": "frontend",
  "version": "0.1.0",
  "description": "Frontend application",
  ...
  "dependencies": {
    ...
    "next": "14.1.0",
    ...
  },
  "devDependencies": {
    "@strapi/strapi": "4.17.1",
    "@strapi/types": "4.17.1",
    ...
  },
  "resolutions": {
    "redux": "5.0.1" // this btw also needs update in strapi, it breaks redux types on latest versions
  },
}

// apps/frontend/src/types/generated/*.d.ts
import type { Schema, Attribute } from '@strapi/strapi';

So since generated types are always bound to @strapi/strapi it needs a hack to change this line on exported typings in external packages. Idc i would suggest to use some sort of flag like --external-dir so it changes it to:

import type { Schema, Attribute } from '@strapi/types';

I know dev dep should not increase bundle, but still feels bit doggy.

Another fun issue with monorepo, that turbo uses command prune for dockerization.

Basically when i deploy i build two containers from monorepo, the frontend and backend. So when i do turbo --prune --scope=frontend i'm not going to have backend in the out folder. Meaning i'm not going to have generated types... That's why currently i commit generated types to repo. The way it works right now i have this scripts in package.json of strapi:

{
  ...
  "scripts": {
    ...
    "types": "yarn types-shared && yarn types-frontend",
    "types-shared": "yarn strapi ts:generate-types --out-dir ./../shared/src/types",
    "types-frontend": "yarn strapi ts:generate-types --out-dir ./../frontend/src/types",
    ...
  },
  ...
}

And i run this before dev, and commit after...
Not sure about a conclusion for this side effect, so far it seems that the best way is to generated types for shared package and commit them, but would be also nice to have import type { Schema, Attribute } from '@strapi/types'; as import....

Going to test tsconfig importing from shared package

[antokhio]

@Convly
Got [WIP] testing rig for monorepos https://github.com/antokhio/turbo-strapi-next-rtk

Bit busy on schedule but thing currently works. Generated types are passed thru tsconfig.
Note: need generate them inside shared package because the backend won't be available after dockerization.

[antokhio]

just wanna share this beauty:

export type Home = StrapiContentType<'api::home.home'>;

type StrapiDbQueryPopulate<T> =
  | '*'
  | {
      select?: (keyof T)[];
      populate:
        | {
            [P in keyof T]: StrapiDbQueryPopulate<T[P]>;
          }
        | boolean
        | {};
    };

const test: StrapiDbQueryPopulate<Home> = {
  populate: {
    advantages: {
      select: [''],
      populate: {},
    },
  },
};

[Convly]

Hey there, I just wanted to share that we've updated some types for v5 (thanks to your input).

Attributes' values are now set as optional and nullable

See

• https://github.com/strapi/strapi/blob/v5/main/packages/core/types/src/data/component.ts#L21-L25
• https://github.com/strapi/strapi/blob/v5/main/packages/core/types/src/data/content-type.ts#L25-L29

For the media type, I'm starting to see how to implement the right type to match the data structure.

Regarding your repo example, thanks for sharing a working solution, it's nice to see that you got everything to work well. I'll look at it more when we start developing our frontend SDK.

[Convly]

just wanna share this beauty:

export type Home = StrapiContentType<'api::home.home'>;

type StrapiDbQueryPopulate<T> =
  | '*'
  | {
      select?: (keyof T)[];
      populate:
        | {
            [P in keyof T]: StrapiDbQueryPopulate<T[P]>;
          }
        | boolean
        | {};
    };

const test: StrapiDbQueryPopulate<Home> = {
  populate: {
    advantages: {
      select: [''],
      populate: {},
    },
  },
};

Glad that you made it work, although I'm curious as to why you need such a type? (I mean, ofc DB types are far from what they should be, but are you using a lot of db queries?)

PS: Does it handle the populate fragments for polymorphic data structures such as morph relations and dynamic zones? 🤔

[antokhio]

@Convly hey, sry for late reply bit on hard schedule...

Yes, we do use db.query a lot, the point is, we don't want to pass populate objects from frontend and strict query params, we did a test with strapi-protected-populate, plug, but seems hardcoded populates still, better (e.g. faster to do by code then clicking in ui), i guess you can think about that as personal preference.

More in depth, we have pipeline with controllers augmentation that adds extra works but keeps code base kinda solid, since we also add custom stuff like breadcrumbs, or querying other CT's, filtering. I'm trying to think of a way to move from that to middlewares and default controllers, but it needs time to align...

[antokhio]

There is also a problems with this approach:

// Will have types of components and relations only `three` levels deep then it's going to be any
export type Home = StrapiContentType<'api::home.home'>; 

type StrapiDbQueryPopulate<T> =
  | '*' // Gonna error on db.query
  | {
      select?: (keyof T)[];
      populate:
        | {
            [P in keyof T]: StrapiDbQueryPopulate<T[P]>;
          }
        | boolean
        | {}; // Prevents strict checking, so not going to error on fields
    };

const test: StrapiDbQueryPopulate<Home> = {
  populate: {
    advantages: {
      populate: {
         features: {
           populate: {
              someComponentOrRelation: {} // < going to be unknown here
           }
         }
      }
    },
  },
};

The version i'm endup currently using:

export type StrapiDbPopulate<T> = {
  select?: (keyof T)[];
  populate?:
    | {
        [P in keyof T]: StrapiDbPopulate<T[P]>;
      }
    | boolean
    | {} // Remove this for `strict` type check
    | (keyof T)[];
} & {
  [key: string]: any;
};

[strapi-bot]

This issue has been mentioned on Strapi Community Forum. There might be relevant details there:

https://forum.strapi.io/t/how-do-i-use-strapis-auto-generate-typescript-types/39181/4