Types for nostr events?

[chmac]

It looks like the .filter() function returns events of type any:

https://github.com/KiPSOFT/nostr-deno/blob/f56d6c01868c3b041c15a3065e3deb1e496f0013/lib/nostr.ts#L151-L165

Are you open to adding types to the events which are output? There's an Event type in the nostr-tools package that could serve as a starting point. Although it has id and sig as optional which is not the case when receiving events from a relay. I tend to wrap it in a Required<Event> when I'm typing events from relays.

[KiPSOFT]

export interface NostrEvent {
    id: string;
    pubkey: string;
    created_at: number;
    kind: NostrKind;
    tags: Array<any>;
    content: string;
    sig: string;
}

The filter method returns three methods: collect, each, and the default return of async iterable. The collect method returns the result in the form of NostrEvent[], which is the same as each. The default return only returns NostrEvent in async iterable returns. NostrEvent is a type that is compatible with the nostr default event type as you mentioned. I couldn't understand your exact needs here, but we are always open to improvements. If you want, you can create a PR while maintaining backwards compatibility.

[chmac]

Ah, okay, so then I think I found a bug. Maybe it's here:

https://github.com/KiPSOFT/nostr-deno/blob/f56d6c01868c3b041c15a3065e3deb1e496f0013/mod.ts#L27948-L27957

The return type of collect seems to be Promise<any[]>

Perhaps it's as simple as adding changing line 27952 to be const events: NostrEvent[] = []?

[chmac]

Ah, wait, now I see that mod.ts is built, when I look at what is maybe the input:

https://github.com/KiPSOFT/nostr-deno/blob/f56d6c01868c3b041c15a3065e3deb1e496f0013/lib/nostr.ts#L169-L175

There the types are set correctly. Could it be that this change is not yet published? I'm looking locally at the files that were downloaded by deno cache. Or, maybe there's a problem occurring during the deno bundle step?

[chmac]

Hmm, just checked the published version (0.2.7) which I'm using, and it does have the correct types in the lib/nostr.ts file: https://deno.land/x/nostr_deno_client@v0.2.7/lib/nostr.ts?source

So maybe that suggests the types are being lost during the deno bundle step?

[KiPSOFT]

Can't properly display the return of the Collect method during code completion?

I will check the type resolution by importing mod.ts with a clean cache.

[chmac]

@KiPSOFT I'm on my phone now, but I remember it that the types are missing in the bundled file, but present in the source file. So I think something in the build (bundle) process is going wrong. Maybe it's actually a bug on the deno side. I didn't try running the bundle on my machine to see if it creates the same output though.