@postman/sdk-config 0.1.1 → 0.2.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.
Files changed (37) hide show
  1. package/README.md +29 -12
  2. package/dist/index.cjs +284 -139
  3. package/dist/index.cjs.map +1 -1
  4. package/dist/index.d.cts +3 -3
  5. package/dist/index.d.ts +3 -3
  6. package/dist/index.js +277 -140
  7. package/dist/index.js.map +1 -1
  8. package/dist/sdk-config/index.cjs +281 -109
  9. package/dist/sdk-config/index.cjs.map +1 -1
  10. package/dist/sdk-config/index.d.cts +2 -2
  11. package/dist/sdk-config/index.d.ts +2 -2
  12. package/dist/sdk-config/index.js +276 -110
  13. package/dist/sdk-config/index.js.map +1 -1
  14. package/dist/sdk-config/v1/index.cjs +281 -109
  15. package/dist/sdk-config/v1/index.cjs.map +1 -1
  16. package/dist/sdk-config/v1/index.d.cts +6903 -289
  17. package/dist/sdk-config/v1/index.d.ts +6903 -289
  18. package/dist/sdk-config/v1/index.js +276 -110
  19. package/dist/sdk-config/v1/index.js.map +1 -1
  20. package/dist/sdk-config-ir/index.cjs +58 -24
  21. package/dist/sdk-config-ir/index.cjs.map +1 -1
  22. package/dist/sdk-config-ir/index.d.cts +2 -2
  23. package/dist/sdk-config-ir/index.d.ts +2 -2
  24. package/dist/sdk-config-ir/index.js +57 -25
  25. package/dist/sdk-config-ir/index.js.map +1 -1
  26. package/dist/sdk-config-ir/v1/index.cjs +58 -24
  27. package/dist/sdk-config-ir/v1/index.cjs.map +1 -1
  28. package/dist/sdk-config-ir/v1/index.d.cts +94 -15
  29. package/dist/sdk-config-ir/v1/index.d.ts +94 -15
  30. package/dist/sdk-config-ir/v1/index.js +57 -25
  31. package/dist/sdk-config-ir/v1/index.js.map +1 -1
  32. package/dist/{typescript-DK97815_.d.cts → typescript-DNqK3T3v.d.cts} +3 -0
  33. package/dist/{typescript-DK97815_.d.ts → typescript-DNqK3T3v.d.ts} +3 -0
  34. package/docs/releasing.md +114 -0
  35. package/package.json +1 -1
  36. package/src/sdk-config/v1/README.md +91 -23
  37. package/src/sdk-config-ir/v1/README.md +3 -2
package/README.md CHANGED
@@ -2,10 +2,10 @@
2
2
 
3
3
  Build and validate SDK Config documents for SDK Generation API requests.
4
4
 
5
- SDK Config describes what to generate: SDK identity, API behavior, client behavior, package
6
- metadata, documentation, output, shared generation options, and one or more language targets. API
7
- source files, authentication, idempotency, and transport metadata belong to the SDK Generation API
8
- request rather than the SDK Config document.
5
+ SDK Config describes what to generate: API source provenance, SDK identity, API behavior, client
6
+ behavior, package metadata, documentation, output, shared generation options, and one or more
7
+ language targets. The materialized API source bytes, authentication, idempotency, and transport
8
+ metadata belong to the SDK Generation API request rather than the SDK Config document.
9
9
 
10
10
  ## Install
11
11
 
@@ -17,13 +17,15 @@ Node.js 24 or newer is required. Both ESM and CommonJS are supported.
17
17
 
18
18
  ## Create and validate an SDK Config
19
19
 
20
- Use the versioned entry point when creating an API payload. `parseSdkConfigV1` validates unknown
21
- input, applies defaults, and returns the normalized `SdkConfigV1` type.
20
+ Use `validateSdkConfigV1` for a customer-authored document. Validation preserves omitted properties
21
+ so persisted configuration is not populated with runtime defaults.
22
22
 
23
23
  ```ts
24
24
  import {
25
25
  parseSdkConfigV1,
26
+ validateSdkConfigV1,
26
27
  type SdkConfigV1,
28
+ type SdkConfigV1Document,
27
29
  type SdkConfigV1Input,
28
30
  } from '@postman/sdk-config/sdk-config/v1';
29
31
 
@@ -31,6 +33,9 @@ const input: SdkConfigV1Input = {
31
33
  schemaVersion: 'sdk-config/v1',
32
34
  sdkName: 'Example SDK',
33
35
  sdkVersion: '1.0.0',
36
+ source: {
37
+ specs: [{ id: 'example', type: 'openapi', path: './openapi.yml' }],
38
+ },
34
39
  api: {},
35
40
  client: { timeoutMs: 30_000 },
36
41
  package: {},
@@ -47,10 +52,12 @@ const input: SdkConfigV1Input = {
47
52
  ],
48
53
  };
49
54
 
50
- const sdkConfig: SdkConfigV1 = parseSdkConfigV1(input);
55
+ const document: SdkConfigV1Document = validateSdkConfigV1(input);
56
+ const sdkConfig: SdkConfigV1 = parseSdkConfigV1(document);
51
57
  ```
52
58
 
53
- For validation without throwing, use the exported schema:
59
+ Use `parseSdkConfigV1` when entering the runtime boundary and materializing the shared domain
60
+ defaults. For validation without throwing, use the exported schema:
54
61
 
55
62
  ```ts
56
63
  import { sdkConfigV1Schema } from '@postman/sdk-config/sdk-config/v1';
@@ -64,6 +71,11 @@ if (!result.success) {
64
71
  SDK Config objects are strict. Unknown fields, duplicate language targets, incompatible package
65
72
  publication settings, and non-exact generator versions are rejected.
66
73
 
74
+ `SdkConfigV1` accepts customer-facing local source paths and HTTP(S) source URLs, but not
75
+ server-owned signed URLs or artifact metadata. See the
76
+ [SDK Config v1 reference](src/sdk-config/v1/README.md) for source materialization and target
77
+ precedence rules.
78
+
67
79
  ## Use SDK Config in an SDK Generation API request
68
80
 
69
81
  An SDK Generation API request combines three kinds of data:
@@ -115,8 +127,9 @@ const response = await fetch('https://api.example.com/sdk-generations', {
115
127
  });
116
128
  ```
117
129
 
118
- The endpoint URL, authentication scheme, source archive format, and response shape are defined by
119
- the SDK Generation API provider.
130
+ Before submitting the request, the client resolves every SDK Config source path or URL and places
131
+ the exact bytes in the source archive. The endpoint URL, authentication scheme, source archive
132
+ format, and response shape are defined by the SDK Generation API provider.
120
133
 
121
134
  This request form supports downloaded archives. Its effective SDK Config output must be
122
135
  `{ "delivery": "zip" }` without publication settings, and `requestedOutput` must be
@@ -140,6 +153,9 @@ A target output replaces the root output; it is not merged with it.
140
153
 
141
154
  These SDK Config values are interpreted as file paths during generation:
142
155
 
156
+ - `source.specs[].path`
157
+ - `source.specs[].overlays[]`
158
+ - `source.specs[].overrides[]`
143
159
  - `generation.customQueryPaths[]`
144
160
  - `generation.workflows[].path`
145
161
  - `generation.hooks.source.location` when `source.type` is `path`
@@ -152,8 +168,9 @@ source locations are not treated as file paths.
152
168
  ## Multiple targets
153
169
 
154
170
  An SDK Config can describe several language targets. Shared `api`, `client`, `docs`, and generation
155
- settings apply to every target. SDK identity, package metadata, output, and language-specific
156
- generation settings can be overridden per target.
171
+ settings apply to every target. SDK identity, client settings, documentation, package metadata,
172
+ output, common generation settings, and language-specific generation settings can be overridden per
173
+ target.
157
174
 
158
175
  Each language can appear only once. When sending a multi-target SDK Config to an SDK Generation API,
159
176
  attach the config under each request target that should select its matching language configuration.