Sync alphalib 2025 05 06 (#226)

* w

* w

* Update template.ts

* Fix deep types error (#227)

* Fix deep types error

One of the big features of TypeScript, is that it can infer types based
on context. This is powerful, but it comes at a cost. Determining types
based on inference consumes much more resources than using a type
annotation. This is an important reason to add explicit type
annotations.

We heavily rely on Zod though. Zod is powerful, but it heavily relies on
inference. This means that by using Zod, we sacrifice type checking
performance. Zod 4 will supposedly be more performant. This is great, but
by definition it can’t be as performant as regular types.

When the types become really complex, TypeScript may error on this. An
explicit type annotation in the right spot fixes this. This PR uses this
to resolve the type error. I can’t explain why this surfaced here, but
not in our internal repos these schemas originate from.

* Update src/alphalib/types/template.ts

---------

Co-authored-by: Kevin van Zonneveld <vanzonneveld@gmail.com>

---------

Co-authored-by: Remco Haszing <remcohaszing@gmail.com>

Author: kvz

examples/convert_to_webp.ts

@@ -32,4 +32,4 @@ const status = await transloadit.createAssembly({
   },
   waitForCompletion: true,
 })
-console.log('Your WebP file:', status.results.webp[0].url)
+console.log('Your WebP file:', status.results?.webp?.[0]?.url)

examples/face_detect_download.ts

@@ -44,7 +44,7 @@ const status = await transloadit.createAssembly({
 // Now save the file
 const outPath = './output-face.jpg'
 const stream = createWriteStream(outPath)
-const { url } = status.results.facesDetected[0]
+const url = status.results?.facesDetected?.[0]?.url
 assert(url != null)
-await got.stream(url).pipe(stream)
+got.stream(url).pipe(stream)
 console.log('Your cropped face has been saved to', outPath)

examples/rasterize_svg_to_png.ts

@@ -30,4 +30,4 @@ const status = await transloadit.createAssembly({
   },
   waitForCompletion: true,
 })
-console.log('Your PNG file:', status.results.png[0].url)
+console.log('Your PNG file:', status.results?.png?.[0]?.url)

examples/resize_an_image.ts

@@ -33,4 +33,4 @@ const status = await transloadit.createAssembly({
   },
   waitForCompletion: true,
 })
-console.log('Your resized image:', status.results.resize[0].url)
+console.log('Your resized image:', status.results?.resize?.[0]?.url)

package.json

@@ -26,7 +26,7 @@
     "is-stream": "^4.0.1",
     "p-map": "^7.0.3",
     "tus-js-client": "^4.3.1",
-    "type-fest": "^4.39.1",
+    "type-fest": "^4.41.0",
     "zod": "^3.24.2"
   },
   "devDependencies": {
@@ -37,7 +37,7 @@
     "@types/temp": "^0.9.4",
     "@typescript-eslint/eslint-plugin": "^8.29.1",
     "@typescript-eslint/parser": "^8.29.1",
-    "@vitest/coverage-v8": "^3.1.1",
+    "@vitest/coverage-v8": "^3.1.3",
     "badge-maker": "^4.1.0",
     "eslint": "8",
     "eslint-config-prettier": "^8.10.0",
@@ -56,7 +56,7 @@
     "prettier": "^3.5.3",
     "temp": "^0.9.4",
     "typescript": "^5.8.3",
-    "vitest": "^3.1.1"
+    "vitest": "^3.1.3"
   },
   "repository": {
     "type": "git",

src/Transloadit.ts

@@ -310,6 +310,12 @@ export class Transloadit {
         }
 
         if (!waitForCompletion) return result
+
+        if (result.assembly_id == null) {
+          throw new InconsistentResponseError(
+            'Server returned an assembly response without an assembly_id after creation'
+          )
+        }
         const awaitResult = await this.awaitAssemblyCompletion(result.assembly_id, {
           timeout,
           onAssemblyProgress,
@@ -341,10 +347,18 @@ export class Transloadit {
     while (true) {
       const result = await this.getAssembly(assemblyId)
 
+      // If 'ok' is not in result, it implies a terminal state (e.g., error, completed, canceled).
+      // If 'ok' is present, then we check if it's one of the non-terminal polling states.
       if (
-        result.ok !== 'ASSEMBLY_UPLOADING' &&
-        result.ok !== 'ASSEMBLY_EXECUTING' &&
-        result.ok !== 'ASSEMBLY_REPLAYING'
+        !('ok' in result) ||
+        (result.ok !== 'ASSEMBLY_UPLOADING' &&
+          result.ok !== 'ASSEMBLY_EXECUTING' &&
+          // ASSEMBLY_REPLAYING is not a valid 'ok' status for polling, it means it's done replaying.
+          // The API does not seem to have an ASSEMBLY_REPLAYING status in the typical polling loop.
+          // It's usually a final status from the replay endpoint.
+          // For polling, we only care about UPLOADING and EXECUTING.
+          // If a replay operation puts it into a pollable state, that state would be EXECUTING.
+          result.ok !== 'ASSEMBLY_REPLAYING') // This line might need review based on actual API behavior for replayed assembly polling
       ) {
         return result // Done!
       }