fix: typescript definitions

[sublimator]

This should make the typescript definitions at least useable. Currently they seem to be quite broken (per #69, #67 )

Closes #54
Closes #47
Closes #69
Closes #67
Closes #62

• Adds examples/typescript and build in CI step
• Fixes definitions (trying to set defaults, chatStream returning wrong type)
• Add signal (per feat: add signal support and fix timeout, closes #5 #68) to typescript definitions
• Fix interfaces (non-exhaustively) per: https://docs.mistral.ai/redocusaurus/plugin-redoc-0.yaml

[sublimator]

@fuegoio

Please look :)

[fuegoio]

Normally there is no name on the message, I think we can remove it.

[fuegoio]

I think we should also remove the enums from the types and change them to types. A simple example like this does not work because the enums are TS only:

import MistralClient, { ResponseFormats } from "@mistralai/mistralai";

const chatResponse = await mistralClient.chat({
    model: "mistral-large",
    temperature: 0.1,
    responseFormat: { type: ResponseFormats.json_object },
})`

This raises the error 'mistralai/src/client.js' does not provide an export named 'ResponseFormats'

[sublimator]

I suppose someone put "name" in there for OpenAI compat reasons at some

point, though it is just misleading, and also not necessary

…

> Message ID: ***@***.***> >

[sublimator]

Oh right, yeah, the enums aren't even defined at runtime are they. I added literals (for ergonomics) and left the enums in there and moved on. They are completely broken though aren't they. A good argument to move to TS :)

…

On Tue, 7 May 2024, 2:51 pm Nicholas Dudfield, ***@***.***> wrote: > > I suppose someone put "name" in there for OpenAI compat reasons at some point, though it is just misleading, and also not necessary > >> Message ID: ***@***.***> >> > — Reply to this email directly, view it on GitHub <#72 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAEAHG6QYRPI5CS72RB4DX3ZBCBWLAVCNFSM6AAAAABHKCIQK6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJXGY3DSOJUHE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[fuegoio]

Oh right, yeah, the enums aren't even defined at runtime are they. I added literals (for ergonomics) and left the enums in there and moved on. They are completely broken though aren't they. A good argument to move to TS :)

In a d.ts file they do not make much sense no. I approve moving to TS to have this kind of nice feature.

[sublimator]

@fuegoio

Anything else? I'll look at a full TS port when I have more time

[sublimator]

Oh, wait, that's not working, enums still referenced, but no errors, hrmmm

[sublimator]

What happened here? :)

[fuegoio]

What do you mean?

[sublimator]

id: 'null';
type: ToolType = ToolType.function;

As you mentioned, the enums don't work at runtime, and null is set to match the string null, not the null type (which is actually not appropriate either). Also, it's trying to set a default (ToolType = ToolType.function;) inside a .d.ts file, which I don't believe actually works.

More a rhetorical question than serious :) Wondering how the ..

[fuegoio]

Yeah the null string is expected, as before our API change the id returned by the API was always 'null' (the string). Now it is function call ids yes. The default stuff well I'm not sure ahah

[sublimator]

I'll look at a full TS port when I have more time

In a separate PR, to be clear

edit: the question is if you all want to merge this ( I think it makes sense, as it's still progress, and closes some issues), or wait for a full TS port

[fuegoio]

Thanks a lot @sublimator!