Fix TypeScript types (retroactively?) / Consider external typing packages

[brokenthorn]

Hello,

First and foremost, this is just a personal suggestion, and I am open to other options if you can provide them, and if not, that is OK too. I just wanted to ask and see what you guys think.

So, we constantly have to fight the provided types from Scheduler Pro and overwrite them, and then forget to check them with every version upgrade, possibly leading to runtime bugs.

In a previous issue #7760, I mentioned one such case, but there are so many others. That ticket was closed and the fix is supposed to be release with v6 alpha, but we cannot wait that long, or do a major version upgrade that easily when it gets out.

Could you possibly consider creating separate @types/* packages for each major/minor version, with patch version to signify new fixes/evolution, allowing these types to be worked on/fixed retroactively, possibly even open them up for outside contribution and PRs?

This would greatly simplify the maintenance of these types, and if Bryntum/you ever have to backport a type fix, you can do it for everyone by just updating the types packages.

This also means that we don't have such a huge maintenance burden by having to check if the latest Scheduler version or whatnot, has provided new types, or fixes for the current overrides each and every one of us has. It's a really tedious and error prone job.

Here are some other examples where lots of types are intersected with any resulting in practically a final type of any.

PS: we would be happy to be first ones to start contributing to these types, provided you can get the ball rolling by exporting the existing types first, into a separate NPM package.

[matsbryntse]

@brokenthorn Thanks for your extensive feedback! We would possibly be open to contributions as long as we can figure out a workflow that works. Would you be open to hopping on a call with us to discuss a few options of how we can make your life easier with regards to typings? Please feel free to send me an email ([email protected])

[brokenthorn]

@matsbryntse, I will contact you via email. Thank you!

[SergeyMaltsev]

@brokenthorn we have removed that any & from typings in 6.0 version already.

It looks like this now:

/**
 * Object with information about the drop points for the dragged events.
 * It is used in the Scheduler's [beforeEventDropFinalize](https://bryntum.com/products/scheduler/docs/api/Scheduler/view/Scheduler#event-beforeEventDropFinalize) event.
 * ...
 * [View online docs...](https://bryntum.com/products/scheduler/docs/api/Scheduler/feature/EventDrag#typedef-DropData)
 */
type DropData = {
    /**
     * The array of drop points for every dragged event.
     */
    events: EventDropData[]
    /**
     * The array of drop points for every dragged assignment.
     */
    assignments: AssignmentDropData[]
}

You may check 6.0.0-alpha-3 version npm packages. https://bryntum.com/products/schedulerpro-next/docs/guide/SchedulerPro/npm-repository

[SergeyMaltsev]

Related to fixed issue here https://github.com/bryntum/support/issues/7760

[SergeyMaltsev]

Type definitions are linked to the exact API code version, so it is not correct to use types from different version. Each major, minor or patch update is bundled with types compatible with the published code.

Publishing it as separate files will certainly lead to inconsistency for someone who used wrong version and we will have even more support requests.

If you have exact code places where we may improve typings, please share with us so we may fix that.

[brokenthorn]

Hello, 👋

That sounds good for the general typings story. A huge fix to be honest. But...

Any chance we could backport these type fixes?

We're not ready for a major version upgrade just yet.

Regards, Paul

On Tue, 14 May 2024, 10:51 Sergey Maltsev, @.***> wrote:

@brokenthorn https://github.com/brokenthorn we have removed that any & from typings in 6.0 version already.

It looks like this now:

/**

• Object with information about the drop points for the dragged events.
• It is used in the Scheduler's beforeEventDropFinalize event.
• ...
• View online docs... / type DropData = { /*
  • The array of drop points for every dragged event. / events: EventDropData[] /*
  • The array of drop points for every dragged assignment. */ assignments: AssignmentDropData[] }

You may check 6.0.0-alpha-3 version npm packages.

https://bryntum.com/products/scheduler-next/docs/guide/Scheduler/npm-repository

— Reply to this email directly, view it on GitHub https://github.com/bryntum/support/issues/9098#issuecomment-2109513127, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQFKXCZJC7EEKEU5RQKJXTZCG67BAVCNFSM6AAAAABHD43RCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBZGUYTGMJSG4 . You are receiving this because you were mentioned.Message ID: @.***>

[brokenthorn]

I understand but you could release types separately with the same version number as the main package they are released with and you could bump both packages' minor versions when fixing types. I know it's a maintenance burden now but in the future you might be able to restructure to create shared types and make the process easier.

Just a thought. I think with how popular TS is getting compared to JS, especially for your enterprise customers this would be a huge quality bump up.

Hopefully your data supports that.

On Tue, 14 May 2024, 11:18 Sergey Maltsev, @.***> wrote:

Type definitions are linked to the exact API code version, so it is not correct to use types from different version. Each major, minor or patch update is bundled with types compatible with the published code.

Publishing it as separate files will certainly lead to inconsistency for someone who used wrong version and we will have even more support requests.

If you have exact code places where we may improve typings, please share with us so we may fix that.

— Reply to this email directly, view it on GitHub https://github.com/bryntum/support/issues/9098#issuecomment-2109564518, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAQFKXEIE3OG23JIWIJQBDTZCHCGHAVCNFSM6AAAAABHD43RCOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBZGU3DINJRHA . You are receiving this because you were mentioned.Message ID: @.***>

[SergeyMaltsev]

I'm afraid it is quite a significant change to be introduced in some 5.6.x patch. That's why we are introducing it in major version update. This may be breaking for client apps.