@shipstatic/types 2.22.0 → 2.23.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/dist/index.d.ts +46 -2
- package/dist/index.js +32 -2
- package/package.json +1 -1
- package/src/index.ts +51 -2
package/dist/index.d.ts
CHANGED
|
@@ -894,6 +894,21 @@ export declare const ErrorType: {
|
|
|
894
894
|
* and opposite retry behaviour.
|
|
895
895
|
*/
|
|
896
896
|
readonly Maintenance: "maintenance";
|
|
897
|
+
/**
|
|
898
|
+
* The project could not be built as submitted (422). The platform ran the
|
|
899
|
+
* caller's own instructions, the dependency install and then the build
|
|
900
|
+
* script, and they failed. So the verdict is the caller's: deterministic,
|
|
901
|
+
* not worth a retry, and answered with the evidence. `details` is a
|
|
902
|
+
* `BuildFailureDetails`, and the message is the one sentence the builder
|
|
903
|
+
* authored for the person who will fix the project.
|
|
904
|
+
*
|
|
905
|
+
* Distinct from `Api` at 500, which is what the platform answers when it
|
|
906
|
+
* could not RUN the build at all (the sandbox failed to start, a host
|
|
907
|
+
* fault). A consumer has to tell "your project cannot be built" from "we
|
|
908
|
+
* could not build it": the two get opposite words, opposite retry
|
|
909
|
+
* behaviour, and only the second pages an operator.
|
|
910
|
+
*/
|
|
911
|
+
readonly Build: "build_failed";
|
|
897
912
|
/** Network/connection error. Client-side only — set by HTTP clients on fetch failure; never produced server-side. */
|
|
898
913
|
readonly Network: "network_error";
|
|
899
914
|
/**
|
|
@@ -934,6 +949,23 @@ export interface ErrorResponse {
|
|
|
934
949
|
/** Optional additional error details. Untyped by design — narrow at the read site. */
|
|
935
950
|
details?: unknown;
|
|
936
951
|
}
|
|
952
|
+
/**
|
|
953
|
+
* `details` of an `ErrorType.Build` error: the evidence behind the verdict.
|
|
954
|
+
*
|
|
955
|
+
* The one `details` shape this file names, because it is the one a HUMAN
|
|
956
|
+
* surface renders rather than a machine reads. The sentence in `message`
|
|
957
|
+
* says what went wrong; the log is how the person fixing the project sees
|
|
958
|
+
* where. A surface that builds shows both, the log as a block rather than
|
|
959
|
+
* as prose.
|
|
960
|
+
*/
|
|
961
|
+
export interface BuildFailureDetails {
|
|
962
|
+
/**
|
|
963
|
+
* The tail of the build's own output, install and build script alike, as
|
|
964
|
+
* the builder wrote it. Bounded by the builder, so a consumer need not cap
|
|
965
|
+
* it again.
|
|
966
|
+
*/
|
|
967
|
+
log: string;
|
|
968
|
+
}
|
|
937
969
|
/**
|
|
938
970
|
* Simple unified error class for both API and SDK
|
|
939
971
|
*/
|
|
@@ -1044,10 +1076,22 @@ export declare class ShipError extends Error {
|
|
|
1044
1076
|
* `message` is REQUIRED and has no default here. The API is the only
|
|
1045
1077
|
* producer of that sentence, and a default in this file would be a second
|
|
1046
1078
|
* owner of one fact — see CLAUDE.md, "The Constellation Law" (stopping
|
|
1047
|
-
* rule). It is also the
|
|
1048
|
-
* defaulted: a maintenance refusal is 503 or it is not this error
|
|
1079
|
+
* rule). It is also the first factory whose status is fixed rather than
|
|
1080
|
+
* defaulted: a maintenance refusal is 503 or it is not this error
|
|
1081
|
+
* (`build` is the second, on the same reasoning).
|
|
1049
1082
|
*/
|
|
1050
1083
|
static maintenance(message: string, details?: unknown): ShipError;
|
|
1084
|
+
/**
|
|
1085
|
+
* The project could not be built as submitted (422).
|
|
1086
|
+
*
|
|
1087
|
+
* The second factory with a FIXED status, on Maintenance's reasoning: a
|
|
1088
|
+
* build verdict is 422 or it is not this error. `message` is the builder's
|
|
1089
|
+
* own sentence, relayed rather than rewritten, since the builder is the
|
|
1090
|
+
* throw site and the only party that knows why; `details` carries the log
|
|
1091
|
+
* (`BuildFailureDetails`), which is required for the same reason a verdict
|
|
1092
|
+
* without evidence is an opinion.
|
|
1093
|
+
*/
|
|
1094
|
+
static build(message: string, details: BuildFailureDetails): ShipError;
|
|
1051
1095
|
/**
|
|
1052
1096
|
* The caller is at fault — by HTTP's own definition of a 4xx, or by a type
|
|
1053
1097
|
* that is client-attributable without ever having a status (`Config`,
|
package/dist/index.js
CHANGED
|
@@ -359,6 +359,21 @@ export const ErrorType = {
|
|
|
359
359
|
* and opposite retry behaviour.
|
|
360
360
|
*/
|
|
361
361
|
Maintenance: 'maintenance',
|
|
362
|
+
/**
|
|
363
|
+
* The project could not be built as submitted (422). The platform ran the
|
|
364
|
+
* caller's own instructions, the dependency install and then the build
|
|
365
|
+
* script, and they failed. So the verdict is the caller's: deterministic,
|
|
366
|
+
* not worth a retry, and answered with the evidence. `details` is a
|
|
367
|
+
* `BuildFailureDetails`, and the message is the one sentence the builder
|
|
368
|
+
* authored for the person who will fix the project.
|
|
369
|
+
*
|
|
370
|
+
* Distinct from `Api` at 500, which is what the platform answers when it
|
|
371
|
+
* could not RUN the build at all (the sandbox failed to start, a host
|
|
372
|
+
* fault). A consumer has to tell "your project cannot be built" from "we
|
|
373
|
+
* could not build it": the two get opposite words, opposite retry
|
|
374
|
+
* behaviour, and only the second pages an operator.
|
|
375
|
+
*/
|
|
376
|
+
Build: 'build_failed',
|
|
362
377
|
/** Network/connection error. Client-side only — set by HTTP clients on fetch failure; never produced server-side. */
|
|
363
378
|
Network: 'network_error',
|
|
364
379
|
/**
|
|
@@ -425,6 +440,7 @@ const ERROR_CATEGORIES = {
|
|
|
425
440
|
* a second attempt.
|
|
426
441
|
*/
|
|
427
442
|
client: new Set([
|
|
443
|
+
ErrorType.Build,
|
|
428
444
|
ErrorType.Business,
|
|
429
445
|
ErrorType.Cancelled,
|
|
430
446
|
ErrorType.Config,
|
|
@@ -791,12 +807,26 @@ export class ShipError extends Error {
|
|
|
791
807
|
* `message` is REQUIRED and has no default here. The API is the only
|
|
792
808
|
* producer of that sentence, and a default in this file would be a second
|
|
793
809
|
* owner of one fact — see CLAUDE.md, "The Constellation Law" (stopping
|
|
794
|
-
* rule). It is also the
|
|
795
|
-
* defaulted: a maintenance refusal is 503 or it is not this error
|
|
810
|
+
* rule). It is also the first factory whose status is fixed rather than
|
|
811
|
+
* defaulted: a maintenance refusal is 503 or it is not this error
|
|
812
|
+
* (`build` is the second, on the same reasoning).
|
|
796
813
|
*/
|
|
797
814
|
static maintenance(message, details) {
|
|
798
815
|
return new ShipError(ErrorType.Maintenance, message, 503, details);
|
|
799
816
|
}
|
|
817
|
+
/**
|
|
818
|
+
* The project could not be built as submitted (422).
|
|
819
|
+
*
|
|
820
|
+
* The second factory with a FIXED status, on Maintenance's reasoning: a
|
|
821
|
+
* build verdict is 422 or it is not this error. `message` is the builder's
|
|
822
|
+
* own sentence, relayed rather than rewritten, since the builder is the
|
|
823
|
+
* throw site and the only party that knows why; `details` carries the log
|
|
824
|
+
* (`BuildFailureDetails`), which is required for the same reason a verdict
|
|
825
|
+
* without evidence is an opinion.
|
|
826
|
+
*/
|
|
827
|
+
static build(message, details) {
|
|
828
|
+
return new ShipError(ErrorType.Build, message, 422, details);
|
|
829
|
+
}
|
|
800
830
|
// Semantic-category guards. For specific-type checks, use
|
|
801
831
|
// `error.type === ErrorType.X` directly or the generic `isType(t)`.
|
|
802
832
|
/**
|
package/package.json
CHANGED
package/src/index.ts
CHANGED
|
@@ -983,6 +983,21 @@ export const ErrorType = {
|
|
|
983
983
|
* and opposite retry behaviour.
|
|
984
984
|
*/
|
|
985
985
|
Maintenance: 'maintenance',
|
|
986
|
+
/**
|
|
987
|
+
* The project could not be built as submitted (422). The platform ran the
|
|
988
|
+
* caller's own instructions, the dependency install and then the build
|
|
989
|
+
* script, and they failed. So the verdict is the caller's: deterministic,
|
|
990
|
+
* not worth a retry, and answered with the evidence. `details` is a
|
|
991
|
+
* `BuildFailureDetails`, and the message is the one sentence the builder
|
|
992
|
+
* authored for the person who will fix the project.
|
|
993
|
+
*
|
|
994
|
+
* Distinct from `Api` at 500, which is what the platform answers when it
|
|
995
|
+
* could not RUN the build at all (the sandbox failed to start, a host
|
|
996
|
+
* fault). A consumer has to tell "your project cannot be built" from "we
|
|
997
|
+
* could not build it": the two get opposite words, opposite retry
|
|
998
|
+
* behaviour, and only the second pages an operator.
|
|
999
|
+
*/
|
|
1000
|
+
Build: 'build_failed',
|
|
986
1001
|
/** Network/connection error. Client-side only — set by HTTP clients on fetch failure; never produced server-side. */
|
|
987
1002
|
Network: 'network_error',
|
|
988
1003
|
/**
|
|
@@ -1053,6 +1068,7 @@ const ERROR_CATEGORIES = {
|
|
|
1053
1068
|
* a second attempt.
|
|
1054
1069
|
*/
|
|
1055
1070
|
client: new Set<ErrorType>([
|
|
1071
|
+
ErrorType.Build,
|
|
1056
1072
|
ErrorType.Business,
|
|
1057
1073
|
ErrorType.Cancelled,
|
|
1058
1074
|
ErrorType.Config,
|
|
@@ -1193,6 +1209,24 @@ export interface ErrorResponse {
|
|
|
1193
1209
|
details?: unknown;
|
|
1194
1210
|
}
|
|
1195
1211
|
|
|
1212
|
+
/**
|
|
1213
|
+
* `details` of an `ErrorType.Build` error: the evidence behind the verdict.
|
|
1214
|
+
*
|
|
1215
|
+
* The one `details` shape this file names, because it is the one a HUMAN
|
|
1216
|
+
* surface renders rather than a machine reads. The sentence in `message`
|
|
1217
|
+
* says what went wrong; the log is how the person fixing the project sees
|
|
1218
|
+
* where. A surface that builds shows both, the log as a block rather than
|
|
1219
|
+
* as prose.
|
|
1220
|
+
*/
|
|
1221
|
+
export interface BuildFailureDetails {
|
|
1222
|
+
/**
|
|
1223
|
+
* The tail of the build's own output, install and build script alike, as
|
|
1224
|
+
* the builder wrote it. Bounded by the builder, so a consumer need not cap
|
|
1225
|
+
* it again.
|
|
1226
|
+
*/
|
|
1227
|
+
log: string;
|
|
1228
|
+
}
|
|
1229
|
+
|
|
1196
1230
|
/**
|
|
1197
1231
|
* Simple unified error class for both API and SDK
|
|
1198
1232
|
*/
|
|
@@ -1464,13 +1498,28 @@ export class ShipError extends Error {
|
|
|
1464
1498
|
* `message` is REQUIRED and has no default here. The API is the only
|
|
1465
1499
|
* producer of that sentence, and a default in this file would be a second
|
|
1466
1500
|
* owner of one fact — see CLAUDE.md, "The Constellation Law" (stopping
|
|
1467
|
-
* rule). It is also the
|
|
1468
|
-
* defaulted: a maintenance refusal is 503 or it is not this error
|
|
1501
|
+
* rule). It is also the first factory whose status is fixed rather than
|
|
1502
|
+
* defaulted: a maintenance refusal is 503 or it is not this error
|
|
1503
|
+
* (`build` is the second, on the same reasoning).
|
|
1469
1504
|
*/
|
|
1470
1505
|
static maintenance(message: string, details?: unknown): ShipError {
|
|
1471
1506
|
return new ShipError(ErrorType.Maintenance, message, 503, details);
|
|
1472
1507
|
}
|
|
1473
1508
|
|
|
1509
|
+
/**
|
|
1510
|
+
* The project could not be built as submitted (422).
|
|
1511
|
+
*
|
|
1512
|
+
* The second factory with a FIXED status, on Maintenance's reasoning: a
|
|
1513
|
+
* build verdict is 422 or it is not this error. `message` is the builder's
|
|
1514
|
+
* own sentence, relayed rather than rewritten, since the builder is the
|
|
1515
|
+
* throw site and the only party that knows why; `details` carries the log
|
|
1516
|
+
* (`BuildFailureDetails`), which is required for the same reason a verdict
|
|
1517
|
+
* without evidence is an opinion.
|
|
1518
|
+
*/
|
|
1519
|
+
static build(message: string, details: BuildFailureDetails): ShipError {
|
|
1520
|
+
return new ShipError(ErrorType.Build, message, 422, details);
|
|
1521
|
+
}
|
|
1522
|
+
|
|
1474
1523
|
// Semantic-category guards. For specific-type checks, use
|
|
1475
1524
|
// `error.type === ErrorType.X` directly or the generic `isType(t)`.
|
|
1476
1525
|
|