[4.2 beta] We can not extends strapi typescript interfaces

[stafyniaksacha]

Bug report

Describe the bug

Strapi comes with two different typing system:

• One that is used internally

import type { StrapiInterface } from '@strapi/strapi'

function myFunction(strapi: StrapiInterface) {
  // here we use the internal strapi interface
}

import { factories } from '@strapi/strapi'
const { createCoreController } = factories

export default createCoreController('api::foo:foo', ({ strapi }) => {
  // here we also use the internal strapi interface
}

• One that is exposed globally

function myFunction() {
  // here we use the global strapi interface
  strapi.log.debug('it works')
}

The interfaces used for internal typing are not exported, so we can not do:

declare module '@strapi/strapi' {
  // use declaration merging
  interface StrapiInterface {
    plugin: (pluginName: 'my-plugin') => any;
  }
}

For now we can do something quite similar for the global part, but il would break all typing provided by arguments on factories.

declare global {
  interface StrapiInterface {
    plugin: (pluginName: string) => any;
  }
  interface AllTypes {
    [key: string]: unknown;
    foo: any;
  }
}

Also the default Strapi Class is not considered in end project because of the type overriding (@strapi/strapi/lib/index.d.ts, when .d.ts file is present, typescript just ignore .js files), so we end up with only query and entityService as Strapi object member:

Expected behavior

The internal type should be the reference and the only interface that need to be updated.

[Convly]

Hey Sacha, the types provided are nowhere near the quality we want them to have in the future. They've been added to provide IntelliSense to JS development during the V4 and haven't been maintained much ever since (which is causing issues in some cases).
Right now I've two potential fixes:

• Delete them (the .d.ts present in strapi/strapi) so that everyone can type Strapi as they wish.
• Makes the types less strict & accept any extension (we would still need to fix the all outdated types which in theory is not the scope of this release)

Those would be temporary solutions as we'll work in the near future on the second iteration of the TS feature which will include typings for user-facing programmatic APIs (plugin API, etc...).

Which solution do you think would fit your (& others) needs the best for the moment?

[stafyniaksacha]

Hi @Convly!
I think you should remove all .d.ts, so it's remove unwanted things.

Then we could take time to either:

• use tsc --declaration --emitDeclarationOnly command to generate types from js
• declare them manually in the project, but it would require great skills with typescript as it can conflict with real code that being executed (https://github.com/type-challenges/type-challenges)
• declare them manually but in the DefinitelyTyped repository, so we can be optionally installed via @types/strapi
• start migrating the strapi codebase to typescript

[Convly]

Hey @stafyniaksacha, here's some update about how we're about to proceed with this issue:

• We felt the need to keep some of the typings for now so that it doesn't break internal stuff.
• We're going to export the StrapiInterface so that users can extend it & benefit from this added freedom.
• The next iterations on Strapi w/ TypeScript will concerns the typings & typings (auto) generation. We'll then rework how we're dealing with them at this point. (<> basically what you shared in your last message)

How does that sound to you?

PS: You can check some more explanations & example in the linked PR (right above this message)

[strapi-bot]

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

https://forum.strapi.io/t/strapi-v4-2-0-second-beta-for-typescript-support/17853/1

[soupette]

I am closing this issue as it been fixed with #13108