@nextlyhq/storage-vercel-blob 0.0.2-alpha.69 → 0.0.2-alpha.70

package/dist/index.cjs

@@ -657,53 +657,7 @@ function ipv4ToInt(ip) {
 	}
 	return acc >>> 0;
 }
-// ../nextly/dist/storage/read-errors.mjs
-/**
-* The one way the storage layer says a read exceeded the caller's cap.
-*
-* `StorageReadOptions.maxBytes` is part of the adapter contract, so what happens
-* when it is exceeded belongs to the contract too. Without this each backend
-* refuses in its own vocabulary — the URL-addressed ones through a fetch error
-* carrying a `reason`, S3 through whatever its own code threw — and a caller
-* wanting to tell "too large" from "could not read" has to know which adapter it
-* is talking to. That is the thing an adapter contract exists to stop.
-*
-* Distinct from a generic internal failure because callers ACT on the
-* difference. The email attachment path answers an over-cap read with
-* `ATTACHMENT_SIZE_EXCEEDED`, which tells an author to attach something smaller;
-* a storage failure tells them nothing they can act on. Collapsing the two turns
-* a fixable refusal into an opaque error, which is the same conflation this
-* contract already draws between a missing key and an unreachable store.
-*
-* @module storage/read-errors
-*/
-/**
-* A read refused because the object is larger than the caller allowed.
-*
-* Carries the numbers rather than only a message, so a caller can say what the
-* limit was without parsing prose — and so the message itself stays free of the
-* key, which should not travel to whoever asked for the file.
-*/
-var StorageReadTooLargeError = class extends NextlyError {
-	path;
-	maxBytes;
-	size;
-	constructor(path, maxBytes, size) {
-		super({
-			code: "STORAGE_READ_TOO_LARGE",
-			publicMessage: "The stored file is larger than the limit for this read.",
-			logContext: {
-				path,
-				maxBytes,
-				...size === void 0 ? {} : { size }
-			}
-		});
-		this.path = path;
-		this.maxBytes = maxBytes;
-		this.size = size;
-	}
-};
-// ../nextly/dist/fetch-stored-bytes-CJ9Uv8it.mjs
+// ../nextly/dist/validate-external-url-uHUKFZGh.mjs
 const IPV4_RE = /^(?:(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)\.){3}(?:25[0-5]|2[0-4]\d|1\d\d|[1-9]?\d)$/;
 /**
 * IPv4 CIDR ranges that must NEVER be the destination of an outbound
@@ -1145,6 +1099,53 @@ function isPublicIpv6(addr, allowLoopback) {
 	if (firstHextet.startsWith("ff")) return false;
 	return true;
 }
+// ../nextly/dist/storage/read-errors.mjs
+/**
+* The one way the storage layer says a read exceeded the caller's cap.
+*
+* `StorageReadOptions.maxBytes` is part of the adapter contract, so what happens
+* when it is exceeded belongs to the contract too. Without this each backend
+* refuses in its own vocabulary — the URL-addressed ones through a fetch error
+* carrying a `reason`, S3 through whatever its own code threw — and a caller
+* wanting to tell "too large" from "could not read" has to know which adapter it
+* is talking to. That is the thing an adapter contract exists to stop.
+*
+* Distinct from a generic internal failure because callers ACT on the
+* difference. The email attachment path answers an over-cap read with
+* `ATTACHMENT_SIZE_EXCEEDED`, which tells an author to attach something smaller;
+* a storage failure tells them nothing they can act on. Collapsing the two turns
+* a fixable refusal into an opaque error, which is the same conflation this
+* contract already draws between a missing key and an unreachable store.
+*
+* @module storage/read-errors
+*/
+/**
+* A read refused because the object is larger than the caller allowed.
+*
+* Carries the numbers rather than only a message, so a caller can say what the
+* limit was without parsing prose — and so the message itself stays free of the
+* key, which should not travel to whoever asked for the file.
+*/
+var StorageReadTooLargeError = class extends NextlyError {
+	path;
+	maxBytes;
+	size;
+	constructor(path, maxBytes, size) {
+		super({
+			code: "STORAGE_READ_TOO_LARGE",
+			publicMessage: "The stored file is larger than the limit for this read.",
+			logContext: {
+				path,
+				maxBytes,
+				...size === void 0 ? {} : { size }
+			}
+		});
+		this.path = path;
+		this.maxBytes = maxBytes;
+		this.size = size;
+	}
+};
+// ../nextly/dist/storage/fetch-stored-bytes.mjs
 /**
 * Reading bytes back from a storage service that only exposes them over HTTP.
 *
@@ -1240,6 +1241,10 @@ function classifyFetchFailure(error) {
 	const successful = error.status !== void 0 && error.status >= 200 && error.status < 300;
 	return error.reason === "response-too-large" && successful ? "oversized" : "unknown";
 }
+/** The deadline a stored read runs under when the caller names none. */
+const DEFAULT_READ_TIMEOUT_MS = DEFAULT_TIMEOUT_MS;
+/** The byte cap a stored read runs under when the caller names none. */
+const DEFAULT_READ_MAX_BYTES = DEFAULT_MAX_RESPONSE_BYTES;
 /**
 * The bounds a read actually runs under, defaults filled in.
 *
@@ -1255,8 +1260,8 @@ function classifyFetchFailure(error) {
 */
 function resolveReadBounds(options) {
 	return {
-		maxBytes: options?.maxBytes ?? 10485760,
-		timeoutMs: options?.timeoutMs ?? 3e4
+		maxBytes: options?.maxBytes ?? DEFAULT_READ_MAX_BYTES,
+		timeoutMs: options?.timeoutMs ?? DEFAULT_READ_TIMEOUT_MS
 	};
 }
 // src/adapter.ts
@@ -1431,7 +1436,7 @@ var VercelBlobStorageAdapter = class {
 	* @returns The blob's bytes, or `null` when it does not exist
 	*/
 	async read(filePath, options) {
-		const deadline = AbortSignal.timeout(options?.timeoutMs ?? 3e4);
+		const deadline = AbortSignal.timeout(options?.timeoutMs ?? DEFAULT_READ_TIMEOUT_MS);
 		let target;
 		try {
 			const meta = await (0, _vercel_blob.head)(filePath, {