openai-node

We have a bit of context about this in the readme: https://github.com/lastmile-ai/aiconfig#what-problem-it-solv.... The main issue with keeping it in code is that it tangles application code with prompts and model-specific logic. That makes it hard to evaluate the genAI parts of the application, and also iterating on the prompts is not as straightforward as opening up a playground. Having the config be the source of truth let's you connect it to your application code (and still source controlled), lets you evaluate the config as the AI artifact, and also lets you open the config in a playground to edit and iterate. For example, compare how much simpler openai function calling becomes with storing the stuff as a config: https://github.com/lastmile-ai/aiconfig/blob/main/cookbooks/... vs using vanilla openai directly (https://github.com/open

A package I help maintain was released about a month ago, and we've had bug reports related to this: https://github.com/openai/openai-node/issues/304#issuecommen... We simply chose to mark Jest 27 as unsupported in this case, but it did cost some debugging time.

Some part of the OpenAI API can stream events, like the “chat completion” endpoint that’s used by ChatGPT to type out its response. However, the official OpenAI Node SDK doesn’t natively support streaming [1] (though it’s the most requested feature [2]). The recommended approach [3] is kind of a nightmare. I used Fern [4] to generate an SDK for the OpenAI API. It makes it a lot easier to stream responses! https://github.com/fern-openai/openai-node#streaming There’s some other niceties of the Fern-generated SDK: - Endpoints organized by resource, e.g. client.audio.transcribe(...) - Properties are camelCase to match JS/TS convention (they are snake_case in OpenAI’s SDK) - The file upload endpoints support Node.js ReadStream, rather than just File [1] https://github.com/openai/openai-node [2] https://github.com/openai/openai-node/issues?q=is