chore: 🐝 Update SDK - Generate 3.3.1

.speakeasy/gen.lock

@@ -1,12 +1,12 @@
 lockVersion: 2.0.0
 id: 7146d910-ec93-46d4-b2c7-5717a58dd471
 management:
-  docChecksum: b5a2c208bc36f884f74846e5b9777fb8
+  docChecksum: 59634240879b8bce1b699c21c7f4f276
   docVersion: 1.0.0
   speakeasyVersion: 1.361.1
   generationVersion: 2.393.4
-  releaseVersion: 3.3.0
-  configChecksum: c57c819eb337867646803b8f83cc7f64
+  releaseVersion: 3.3.1
+  configChecksum: 7ebb1940798499b899babe33ab6f6e13
   repoURL: https://github.com/livepeer/livepeer-js.git
   installationURL: https://github.com/livepeer/livepeer-js
   published: true

.speakeasy/workflow.lock

@@ -2,17 +2,17 @@ speakeasyVersion: 1.361.1
 sources:
     livepeer-studio-api:
         sourceNamespace: livepeer-studio-api
-        sourceRevisionDigest: sha256:353f7705b22bd4d8752ae70ee51108278e5851840859ea22ff21ebd185167d83
-        sourceBlobDigest: sha256:dc5764ae552f1fa5f17dc9d84c3e49ddb1208e4096f65357ec5aae7657f8afb6
+        sourceRevisionDigest: sha256:df045b530898c3d37fdccef933fdd51e542fac3212b140a2c1d1156aa7505136
+        sourceBlobDigest: sha256:4ecb94fc7baced1d251f061894ebe0b12b9688473ceec039afea6b81edd61dc5
         tags:
             - latest
             - main
 targets:
     livepeer-ts:
         source: livepeer-studio-api
         sourceNamespace: livepeer-studio-api
-        sourceRevisionDigest: sha256:353f7705b22bd4d8752ae70ee51108278e5851840859ea22ff21ebd185167d83
-        sourceBlobDigest: sha256:dc5764ae552f1fa5f17dc9d84c3e49ddb1208e4096f65357ec5aae7657f8afb6
+        sourceRevisionDigest: sha256:df045b530898c3d37fdccef933fdd51e542fac3212b140a2c1d1156aa7505136
+        sourceBlobDigest: sha256:4ecb94fc7baced1d251f061894ebe0b12b9688473ceec039afea6b81edd61dc5
         outLocation: .
 workflow:
     workflowVersion: 1.0.0

FUNCTIONS.md

@@ -0,0 +1,168 @@
+# Standalone Functions
+
+> [!NOTE]
+> This section is useful if you are using a bundler and targetting browsers and
+> runtimes where the size of an application affects performance and load times. 
+
+Every method in this SDK is also available as a standalone function. This
+alternative API is suitable when targetting the browser or serverless runtimes
+and using a bundler to build your application since all unused functionality
+will be tree-shaken away. This includes code for unused methods, Zod schemas,
+encoding helpers and response handlers. The result is dramatically smaller
+impact on the application's final bundle size which grows very slowly as you use
+more and more functionality from this SDK.
+
+Calling methods through the main SDK class remains a valid and generally more
+more ergonomic option. Standalone functions represent an optimisation for a
+specific category of applications.
+
+## Example
+
+```typescript
+import { LivepeerCore } from "livepeer/core.js";
+import { streamCreate } from "livepeer/funcs/streamCreate.js";
+import { Profile, TranscodeProfileEncoder, TranscodeProfileProfile, Type } from "livepeer/models/components";
+import { SDKValidationError } from "livepeer/models/errors/sdkvalidationerror.js";
+
+// Use `LivepeerCore` for best tree-shaking performance.
+// You can create one instance of it to use across an application.
+const livepeer = new LivepeerCore({
+  apiKey: "<YOUR_BEARER_TOKEN_HERE>",
+});
+
+async function run() {
+  const res = await streamCreate(livepeer, {
+    name: "test_stream",
+    pull: {
+      source: "https://myservice.com/live/stream.flv",
+      headers: {
+        "Authorization": "Bearer 123",
+      },
+      location: {
+        lat: 39.739,
+        lon: -104.988,
+      },
+    },
+    playbackPolicy: {
+      type: Type.Webhook,
+      webhookId: "1bde4o2i6xycudoy",
+      webhookContext: {
+        "streamerId": "my-custom-id",
+      },
+      refreshInterval: 600,
+    },
+    profiles: [
+      {
+        width: 1280,
+        name: "720p",
+        height: 720,
+        bitrate: 3000000,
+        fps: 30,
+        fpsDen: 1,
+        quality: 23,
+        gop: "2",
+        profile: Profile.H264Baseline,
+      },
+    ],
+    record: false,
+    recordingSpec: {
+      profiles: [
+        {
+          width: 1280,
+          name: "720p",
+          height: 720,
+          bitrate: 3000000,
+          quality: 23,
+          fps: 30,
+          fpsDen: 1,
+          gop: "2",
+          profile: TranscodeProfileProfile.H264Baseline,
+          encoder: TranscodeProfileEncoder.H264,
+        },
+      ],
+    },
+    multistream: {
+      targets: [
+        {
+          profile: "720p",
+          videoOnly: false,
+          id: "PUSH123",
+          spec: {
+            name: "My target",
+            url: "rtmps://live.my-service.tv/channel/secretKey",
+          },
+        },
+      ],
+    },
+  });
+
+  switch (true) {
+    case res.ok:
+      // The success case will be handled outside of the switch block
+      break;
+    case res.error instanceof SDKValidationError:
+      // Pretty-print validation errors.
+      return console.log(res.error.pretty());
+    case res.error instanceof Error:
+      return console.log(res.error);
+    default:
+      // TypeScript's type checking will fail on the following line if the above
+      // cases were not exhaustive.
+      res.error satisfies never;
+      throw new Error("Assertion failed: expected error checks to be exhaustive: " + res.error);
+  }
+
+
+  const { value: result } = res;
+
+  // Handle the result
+  console.log(result)
+}
+
+run();
+```
+
+## Result types
+
+Standalone functions differ from SDK methods in that they return a
+`Result<Value, Error>` type to capture _known errors_ and document them using
+the type system. By avoiding throwing errors, application code maintains clear
+control flow and error-handling become part of the regular flow of application
+code.
+
+> We use the term "known errors" because standalone functions, and JavaScript
+> code in general, can still throw unexpected errors such as `TypeError`s,
+> `RangeError`s and `DOMException`s. Exhaustively catching all errors may be
+> something this SDK addresses in the future. Nevertheless, there is still a lot
+> of benefit from capturing most errors and turning them into values.
+
+The second reason for this style of programming is because these functions will
+typically be used in front-end applications where exception throwing is
+sometimes discouraged or considered unidiomatic. React and similar ecosystems
+and libraries tend to promote this style of programming so that components
+render useful content under all states (loading, success, error and so on).
+
+The general pattern when calling standalone functions looks like this:
+
+```typescript
+import { Core } from "<sdk-package-name>";
+import { fetchSomething } from "<sdk-package-name>/funcs/fetchSomething.js";
+
+const client = new Core();
+
+async function run() {
+  const result = await fetchSomething(client, { id: "123" });
+  if (!result.ok) {
+    // You can throw the error or handle it. It's your choice now.
+    throw result.error;
+  }
+
+  console.log(result.value);
+}
+
+run();
+```
+
+Notably, `result.error` above will have an explicit type compared to a try-catch
+variation where the error in the catch block can only be of type `unknown` (or
+`any` depending on your TypeScript settings).

RELEASES.md

@@ -64,4 +64,14 @@ Based on:
 ### Generated
 - [typescript v3.3.0] .
 ### Releases
-- [NPM v3.3.0] https://www.npmjs.com/package/livepeer/v/3.3.0 - .
+- [NPM v3.3.0] https://www.npmjs.com/package/livepeer/v/3.3.0 - .
+
+## 2024-08-23 00:19:52
+### Changes
+Based on:
+- OpenAPI Doc  
+- Speakeasy CLI 1.377.3 (2.404.2) https://github.com/speakeasy-api/speakeasy
+### Generated
+- [typescript v3.3.1] .
+### Releases
+- [NPM v3.3.1] https://www.npmjs.com/package/livepeer/v/3.3.1 - .