Type 'typeof import("@event-calendar/core")' has no construct signatures.ts

[im-Qarch]

in my case when i import calendar like this

import Calendar from '@event-calendar/core'

got ts error

[vkurko]

Please see #95

[blujedis]

@vkurko if you think you'll keep up with patches/fixes/releases over the next couple years I may be able to commit some time on the Types. Let me know your thoughts.

[vkurko]

@vkurko if you think you'll keep up with patches/fixes/releases over the next couple years I may be able to commit some time on the Types. Let me know your thoughts.

I can say that I am not going to abandon the library, so your help with the types will be very useful.

[syncsynchalt]

I've been doing some parallel work to this lately, and just noticed this issue.

@blujedis what are your thoughts/plans on how to generate type info? I'm not familiar with Svelte to know its support for generating type info, can it generate a .d.ts without too much work? That seems like the best long-term solution.

Alternatively, we could solve this issue by giving Vladimir a hand-made .d.ts to put into the npm package, and keep it in sync manually going forward. The downsides there are (a) a bit of testing/review needed for the hand-made file, and (b) ongoing manual changes needed any time the library interface changes.

I've got a .d.ts written for @event-calendar/core that I use on my project, it describes the complete interface (as documented in README.md) and is working for me but I only exercise 1/2 or 1/3 of the library options so it could use some eyes or testers. I'm not familiar with npm library packaging but I think you can just package this as-is in the @event-calendar/core distribution and everything will Just Work:
index.d.ts

Additionally, in each of the plugins you'd want to distribute an index.d.ts like this:

export default Interaction

(change name as necessary for each plugin).

---

If anyone in this issue (or in issue #95) wants to test this against their codebase, you should be able to drop the attached index.d.ts file in your codebase as calendar.d.ts and wrap the file contents in a declare module statement, such as:

declare module '@event-calendar/core' {
    export default class Calendar {
    ... snip rest of file contents ...
    }
} 

and add another calendar-plugins.d.ts with the following contents, at least it seems to keep WebStorm and tsc happy in my project:

declare module '@event-calendar/time-grid'
declare module '@event-calendar/resource-time-grid'
declare module '@event-calendar/interaction'
... (plus any other plugins you use) ...

[blujedis]

Long term it would be best in the source itself for many reasons. Although Vladimir would really need to opt in on that. I think it would be a bad Idea to handicap the lead if he’s not that familiar with TS. Svelte uses Vite and it’s pretty good at bundling libraries. It’s a bit of a catch 22 though. Without knowing the lib in and out, it’s somewhat trivial to rewrite as a typed file and just let whatever builder/bundler do its thing and output the type definitions for you. Writing the declaration files can often result in things being a bit out of sync for obvious reasons. However this may be better for Vladimir as I mention. At the moment I’d yield to you. Sounds like you’ve looked at it more than I have. I’m going to be spinning up that project late next week so I’ll have a better handle on things at that point. I suspect adding type defs to this project really will help the project overall.

…

On Aug 15, 2024 at 7:46 PM -0700, Michael Driscoll ***@***.***>, wrote: I've been doing some parallel work to this lately, and just noticed this issue. @blujedis what are your thoughts/plans on how to generate type info? I'm not familiar with Svelte to know its support for generating type info, can it generate a .d.ts without too much work? That seems like the best long-term solution. Alternately, we could solve this issue by giving Vladimir a hand-made .d.ts to put into the npm package, and keep it in sync manually going forward. The downsides there are (a) a bit of testing/review needed for the hand-made file, and (b) ongoing manual changes needed any time the library interface changes. I've got a .d.ts written for @event-calendar/core that I use on my project, it's working for me but I only exercise 1/2 or 1/3 of the library options so it could use some eyes or testers. I'm not familiar with npm library packaging but I think you can just package this as-is in the @event-calendar/core distribution and everything will Just Work: index.d.ts Additionally, in each of the plugins you'd want to distribute an index.d.ts like this: export default Interaction (change as necessary for each plugin). If anyone in this issue (or in issue #95) wants to test this against their codebase, you should be able to drop the attached index.d.ts file in your codebase as calendar.d.ts and wrap the file contents in a declare module statement, such as: declare module ***@***.***/core' { export default class Calendar { ... snip rest of file contents ... } } and add another calendar-plugins.d.ts with the following contents, at least it seems to keep WebStorm and tsc happy in my project: declare module ***@***.***/time-grid' declare module ***@***.***/resource-time-grid' declare module ***@***.***/interaction' ... (plus any other plugins you use) ... — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.Message ID: ***@***.***>

[syncsynchalt]

I'll start looking into best practices for distributing type info (I've only ever used TS in a self-contained sense, so anything declare is new to me). Then I'll work on a PR to get a sense of what it'll look like.

If you or anyone else comes along and does things "right" (with auto-generated type info from the source) I've got no problem throwing away what I've got, so that's not a problem.

[syncsynchalt]

I just noticed this issue is closed, I'll add a note to #95 with a reference to here. Let's move discussion back there.