@voxgig/sdkgen-infrapack 0.0.3 → 0.0.5

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.
@@ -42,6 +42,46 @@ main: kit: target: 'seneca-provider': {
42
42
  test: { active: false }
43
43
  }
44
44
 
45
+ # HOW THIS PROVIDER DEPENDS ON THE SDK IT WRAPS.
46
+ #
47
+ # Default: the PUBLISHED package, pinned to the version the `ts` target
48
+ # publishes, so the two can never disagree. That is right whenever the SDK
49
+ # is on a registry.
50
+ #
51
+ # It is not always on one. An SDK generated for a private API, or one not
52
+ # published yet, leaves the provider with a dependency that cannot resolve
53
+ # — `npm install` fails with a 404 and the provider cannot be built, tested
54
+ # or released at all. `kind: 'git'` points the dependency at a GIT TAG
55
+ # instead, which needs no registry.
56
+ #
57
+ # A PROJECT DECISION, not an API fact, so it belongs in the project overlay
58
+ # (`model/project.aon`) — `target add` overwrites THIS file:
59
+ #
60
+ # main: kit: target: 'seneca-provider': sdk: dep: {
61
+ # kind: 'git'
62
+ # ref: 'v0.1.0'
63
+ # }
64
+ #
65
+ # `repo` defaults to the SDK's own repository, so normally only the ref is
66
+ # stated.
67
+ #
68
+ # `path` is the SUBDIRECTORY the SDK package sits in, because npm resolves
69
+ # a git dependency against the repository root and sdkgen generates the
70
+ # TypeScript SDK into `ts/`. It therefore defaults to `ts` — the layout
71
+ # this toolchain produces — and npm spells it `#<ref>::path:<path>`. Set it
72
+ # to `.` for an SDK whose package.json IS the repository root.
73
+ #
74
+ # `spec` states the whole dependency value outright and wins over
75
+ # everything, for anything the shorthand cannot express — a release-tarball
76
+ # URL, say.
77
+ sdk: dep: {
78
+ kind: *'npm' | 'git'
79
+ ref: *'' | string
80
+ repo: *'' | string
81
+ path: *'ts' | string
82
+ spec: *'' | string
83
+ }
84
+
45
85
  # `kind` is a COMMA-SEPARATED LIST of manifest sections, not a single one.
46
86
  # collectDeps deduplicates by package name and this map is keyed by name, so
47
87
  # a package belonging in two sections cannot be declared twice — it says so
@@ -59,8 +99,6 @@ main: kit: target: 'seneca-provider': {
59
99
  # The ts SDK dependency is emitted by Main from the model's published
60
100
  # package name, so it is not declared here.
61
101
  deps: {
62
- '@seneca/maintain': { active: true, version: '^0.1.0', kind: prod }
63
-
64
102
  '@seneca/env': { active: true, version: '>=0.4', kind: peer }
65
103
  '@seneca/provider': { active: true, version: '>=4', kind: peer }
66
104
 
@@ -77,6 +115,14 @@ main: kit: target: 'seneca-provider': {
77
115
  'seneca-promisify': { active: true, version: '>=3', kind: peer }
78
116
 
79
117
  '@seneca/doc': { active: true, version: '^8.0.0', kind: dev }
118
+
119
+ # DEV, not prod. Its only use is `require('@seneca/maintain')` in the
120
+ # GENERATED TEST FILE, beside seneca-msg-test — the repository-hygiene
121
+ # check the suite runs on itself. Declared prod, every application that
122
+ # installed a generated provider installed that maintenance tooling and
123
+ # its tree along with it, for code it never runs.
124
+ '@seneca/maintain': { active: true, version: '^0.1.0', kind: dev }
125
+
80
126
  '@types/node': { active: true, version: '^24.0.0', kind: dev }
81
127
  'seneca-msg-test': { active: true, version: '^4.1.0', kind: dev }
82
128
  'typescript': { active: true, version: '^5.4.5', kind: dev }