@voxgig/sdkgen-infrapack 0.0.12 → 0.0.14
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/.sdk/model/target/seneca-provider.aon +6 -126
- package/.sdk/src/cmp/seneca-provider/Extras_seneca-provider.ts +256 -655
- package/.sdk/src/cmp/seneca-provider/Gitignore_seneca-provider.ts +0 -21
- package/.sdk/src/cmp/seneca-provider/Main_seneca-provider.ts +190 -621
- package/package.json +7 -7
- package/sdkgen-package.json +2 -2
|
@@ -1,25 +1,3 @@
|
|
|
1
|
-
# Seneca provider target — a Seneca plugin that exposes this API's entities
|
|
2
|
-
# as Seneca entities (`provider/<name>/<entity>`), layered on the sibling
|
|
3
|
-
# `ts` SDK. It is not a language SDK in its own right, so every standard
|
|
4
|
-
# generation phase is switched off below and Main_seneca-provider emits the
|
|
5
|
-
# whole package, exactly as go-cli / go-mcp / py-data do.
|
|
6
|
-
#
|
|
7
|
-
# Requires the `ts` target in the same SDK project (Main throws when it is
|
|
8
|
-
# absent): the plugin imports the published TypeScript SDK.
|
|
9
|
-
#
|
|
10
|
-
# UNLIKE the other consumer targets, this one generates into ITS OWN REPO.
|
|
11
|
-
# A Seneca provider is an independently released npm package under the
|
|
12
|
-
# @seneca scope, with its own LICENSE, CI workflow and release cadence, and
|
|
13
|
-
# it depends on the SDK as an ordinary published dependency rather than by
|
|
14
|
-
# path. Point it at that repo from the PROJECT model:
|
|
15
|
-
#
|
|
16
|
-
# main: kit: target: 'seneca-provider': output: path: '../../seneca/seneca-acme-provider'
|
|
17
|
-
#
|
|
18
|
-
# Relative to the SDK repo root. Left unset here on purpose — every project's
|
|
19
|
-
# provider repo is somewhere different, and a concrete value here would
|
|
20
|
-
# CONFLICT with the project's rather than yield to it (see the publication
|
|
21
|
-
# note below). Unset means the ordinary in-tree `<sdk-repo>/seneca-provider/`,
|
|
22
|
-
# which is a usable default for a first look at the output.
|
|
23
1
|
|
|
24
2
|
main: kit: target: 'seneca-provider': {
|
|
25
3
|
|
|
@@ -30,10 +8,6 @@ main: kit: target: 'seneca-provider': {
|
|
|
30
8
|
base: 'BASE'
|
|
31
9
|
srcfeature: false
|
|
32
10
|
|
|
33
|
-
# Per-generation-phase activation. Mirrors py-data: every standard phase is
|
|
34
|
-
# off and Main emits the package. README, docs and tests ARE generated — by
|
|
35
|
-
# Main, not by the standard cmps, which assume an SDK-shaped package and
|
|
36
|
-
# would emit wrong content here.
|
|
37
11
|
phase: {
|
|
38
12
|
entity: { active: false }
|
|
39
13
|
feature: { active: false }
|
|
@@ -42,61 +16,6 @@ main: kit: target: 'seneca-provider': {
|
|
|
42
16
|
test: { active: false }
|
|
43
17
|
}
|
|
44
18
|
|
|
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
|
-
# WHICH KIND TO USE DEPENDS ON WHERE THE PACKAGE SITS. npm resolves a git
|
|
69
|
-
# dependency against the repository ROOT, and sdkgen generates the
|
|
70
|
-
# TypeScript SDK into `ts/` — so `git` suits an SDK that IS its repository
|
|
71
|
-
# root, and `release` suits this toolchain's own layout:
|
|
72
|
-
#
|
|
73
|
-
# kind: 'git' github:owner/repo#<ref>
|
|
74
|
-
# kind: 'release' https://github.com/owner/repo/releases/download/
|
|
75
|
-
# <ref>/<asset>.tgz
|
|
76
|
-
#
|
|
77
|
-
# A release asset is `npm pack` output attached to the tag; npm installs an
|
|
78
|
-
# https tarball natively and never looks at the repository layout. `asset`
|
|
79
|
-
# names the file when it is not the usual `<scope>-<name>-<version>.tgz`.
|
|
80
|
-
#
|
|
81
|
-
# There is no subdirectory option, deliberately. npm's spec parser accepts
|
|
82
|
-
# `#<ref>::path:ts` and reports a gitSubdir, so it reads as supported — but
|
|
83
|
-
# the INSTALLER ignores it and fails with ENOENT, on linux, macOS and
|
|
84
|
-
# Windows alike. A knob that produces an uninstallable dependency is worse
|
|
85
|
-
# than no knob.
|
|
86
|
-
#
|
|
87
|
-
# NPM 12 REFUSES BOTH BY DEFAULT. `allow-git` and `allow-remote` default to
|
|
88
|
-
# "none", so a git or tarball dependency is rejected before anything is
|
|
89
|
-
# fetched (EALLOWGIT / EALLOWREMOTE). The generated CI passes the matching
|
|
90
|
-
# `--allow-*=all` for whichever kind is configured, because the project
|
|
91
|
-
# opting into what it declared is reasonable — but a CONSUMER of the
|
|
92
|
-
# published provider gets no such flag, and will hit the same wall.
|
|
93
|
-
#
|
|
94
|
-
# So this is a stopgap for an SDK that is not published YET, not a
|
|
95
|
-
# substitute for publishing it. An SDK on a registry needs none of it, and
|
|
96
|
-
# the default `npm` kind is the one that works everywhere.
|
|
97
|
-
#
|
|
98
|
-
# `spec` states the whole dependency value outright and wins over
|
|
99
|
-
# everything.
|
|
100
19
|
sdk: dep: {
|
|
101
20
|
kind: *'npm' | 'git' | 'release'
|
|
102
21
|
ref: *'' | string
|
|
@@ -105,37 +24,20 @@ main: kit: target: 'seneca-provider': {
|
|
|
105
24
|
spec: *'' | string
|
|
106
25
|
}
|
|
107
26
|
|
|
108
|
-
# `kind` is a COMMA-SEPARATED LIST of manifest sections, not a single one.
|
|
109
|
-
# collectDeps deduplicates by package name and this map is keyed by name, so
|
|
110
|
-
# a package belonging in two sections cannot be declared twice — it says so
|
|
111
|
-
# here instead. See `seneca` below for the case that forced it.
|
|
112
27
|
deps: &: {
|
|
113
28
|
kind: *'prod' | string
|
|
114
29
|
}
|
|
115
30
|
|
|
116
|
-
# The
|
|
117
|
-
#
|
|
118
|
-
# framework a plugin runs inside and so are PEER deps — a plugin that
|
|
119
|
-
# bundled its own seneca would run against a different instance than the
|
|
120
|
-
# application it is loaded into.
|
|
121
|
-
#
|
|
122
|
-
# The ts SDK dependency is emitted by Main from the model's published
|
|
123
|
-
# package name, so it is not declared here.
|
|
31
|
+
# The host framework and its plugins: peers of the application, and dev
|
|
32
|
+
# dependencies of the generated suite, which loads every one of them.
|
|
124
33
|
deps: {
|
|
125
|
-
'@seneca/env': { active: true, version: '>=0.4', kind: peer }
|
|
126
|
-
'@seneca/provider': { active: true, version: '>=4', kind: peer }
|
|
34
|
+
'@seneca/env': { active: true, version: '>=0.4', kind: 'peer,dev' }
|
|
35
|
+
'@seneca/provider': { active: true, version: '>=4', kind: 'peer,dev' }
|
|
127
36
|
|
|
128
|
-
# PEER *and* DEV. Peer for the reason above — the plugin must attach to
|
|
129
|
-
# the host application's seneca instance. Dev because the generated test
|
|
130
|
-
# suite does `require('seneca')` itself, so a clean `npm install && npm
|
|
131
|
-
# test` in a fresh checkout has to produce one. Relying on npm's automatic
|
|
132
|
-
# peer installation instead is what dropping this from the manifest
|
|
133
|
-
# amounted to, and that is npm-version- and client-specific: pnpm and
|
|
134
|
-
# `--legacy-peer-deps` both leave the suite with no seneca to require.
|
|
135
37
|
'seneca': { active: true, version: '>=3||>=4.0.0-rc2', kind: 'peer,dev' }
|
|
136
38
|
|
|
137
|
-
'seneca-entity': { active: true, version: '>=26', kind: peer }
|
|
138
|
-
'seneca-promisify': { active: true, version: '>=3', kind: peer }
|
|
39
|
+
'seneca-entity': { active: true, version: '>=26', kind: 'peer,dev' }
|
|
40
|
+
'seneca-promisify': { active: true, version: '>=3', kind: 'peer,dev' }
|
|
139
41
|
|
|
140
42
|
'@seneca/doc': { active: true, version: '^8.0.0', kind: dev }
|
|
141
43
|
|
|
@@ -153,33 +55,11 @@ main: kit: target: 'seneca-provider': {
|
|
|
153
55
|
}
|
|
154
56
|
|
|
155
57
|
|
|
156
|
-
# Feature-deps map slot — every target carries this so the same feature can
|
|
157
|
-
# specify per-target dep variants.
|
|
158
58
|
main: kit: feature: &: target: 'seneca-provider': deps: &: {
|
|
159
59
|
kind: *'prod' | string
|
|
160
60
|
}
|
|
161
61
|
|
|
162
62
|
|
|
163
|
-
# Publication: npm registry, under the @seneca scope rather than the SDK's
|
|
164
|
-
# own. The package name is NOT derived from the SDK slug the way a language
|
|
165
|
-
# target's is — a provider is `@seneca/<name>-provider` — so Main sets it
|
|
166
|
-
# from the model and a project can pin it like any other.
|
|
167
|
-
#
|
|
168
|
-
# `target add <t>` OVERWRITES this file, so a project must never set its
|
|
169
|
-
# publication values here — voxgig-solardemo-sdk lost its pinned npm package
|
|
170
|
-
# name exactly that way. Set them in the project's own overlay
|
|
171
|
-
# (`model/project.aon`), which create-sdkgen creates once and never
|
|
172
|
-
# overwrites — NOT `model/sdk.aon`, which it rewrites on every scaffold.
|
|
173
|
-
#
|
|
174
|
-
# For that to work this file must LEAVE THOSE KEYS UNSET: in aontu a concrete
|
|
175
|
-
# value does not yield to another concrete value, it CONFLICTS, and two
|
|
176
|
-
# defaults conflict too. The schema (@voxgig/sdkgen/model/sdkgen.aon)
|
|
177
|
-
# already defaults `tag.active`, `registry.state`, `registry.active` and
|
|
178
|
-
# `registry.package`, so a project's concrete value wins over the default and
|
|
179
|
-
# repeating them here would only take that away.
|
|
180
|
-
#
|
|
181
|
-
# What remains below is per-target registry IDENTITY, which is not a project
|
|
182
|
-
# choice and stays concrete.
|
|
183
63
|
main: kit: target: 'seneca-provider': publish: {
|
|
184
64
|
registry: {
|
|
185
65
|
name: 'npm'
|