@saptools/service-flow 0.1.10 → 0.1.12
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/CHANGELOG.md +20 -0
- package/README.md +11 -3
- package/dist/{chunk-LQT67AU5.js → chunk-MXYYARUP.js} +238 -95
- package/dist/chunk-MXYYARUP.js.map +1 -0
- package/dist/cli.js +220 -46
- package/dist/cli.js.map +1 -1
- package/dist/index.d.ts +4 -0
- package/dist/index.js +1 -1
- package/package.json +1 -1
- package/dist/chunk-LQT67AU5.js.map +0 -1
package/CHANGELOG.md
CHANGED
|
@@ -1,5 +1,25 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
+
## 0.1.12
|
|
4
|
+
|
|
5
|
+
- Resolved same-repository local CAP service calls by qualified CDS name, simple service name, and service path, with explicit local transport and alias-chain evidence.
|
|
6
|
+
- Made implementation matching decorator-aware so generated `Func*`/`Action*` constants outrank method-name fallback and contradictory decorators are rejected without making edges ambiguous.
|
|
7
|
+
- Cleared stale unresolved reasons from resolved symbol calls and suppressed false trace unresolved reasons for symbol edges with concrete callee ids.
|
|
8
|
+
- Made local symbol-call collection conservative, added named export-list support, and indexed one-level object-literal helper methods as executable symbols so traces can reach helper database queries.
|
|
9
|
+
- Added first-class symbol nodes and readable symbol labels/locations to JSON, table, and Mermaid trace output.
|
|
10
|
+
- Deduplicated implementation candidates by method identity while retaining multiple registration rows as nested evidence, and kept default doctor output from failing on explainable source-ownership gaps.
|
|
11
|
+
- Documented the generated-constant decision: this patch uses deterministic decorator normalization for linking while `parseGeneratedConstants` remains a low-level parser export rather than a persisted graph fact.
|
|
12
|
+
|
|
13
|
+
## 0.1.11
|
|
14
|
+
|
|
15
|
+
- Added repository-owned executable symbols, source-symbol ownership for outbound calls, and local symbol-call facts so traces can follow reachable same-file/imported helpers without including unrelated calls from the same file.
|
|
16
|
+
- Replaced local CAP service call extraction with AST alias tracking for `cds.services` lookups, ignored entity accessors, and linked local calls to exact local operations with explicit local transport evidence.
|
|
17
|
+
- Scoped service/path trace starts by repository, reports ambiguous starts instead of choosing the first row, and queues resolved implementation handlers by their handler repository and symbol identity.
|
|
18
|
+
- Deduplicated operation implementation candidates by logical identity while preserving distinct registration evidence in nested arrays.
|
|
19
|
+
- Link output now reports implementation-unresolved counts, table evidence falls back to nested implementation source locations, and depth `step` values remain within the requested scope depth.
|
|
20
|
+
- Generated-constant claims were removed from runtime documentation until persistence and resolution are fully integrated.
|
|
21
|
+
- Doctor now reports aggregate analyzer-quality diagnostics for systematic local-service, source-symbol, and trace-scope problems.
|
|
22
|
+
|
|
3
23
|
## 0.1.10
|
|
4
24
|
|
|
5
25
|
- Persist unresolved `OPERATION_IMPLEMENTED_BY_HANDLER` audit edges when implementation candidates exist but all are rejected, including ranked candidate evidence and rejected reasons.
|
package/README.md
CHANGED
|
@@ -21,7 +21,7 @@ Index independent Git repositories, persist CAP/CDS facts in SQLite, resolve cro
|
|
|
21
21
|
## ✨ Features
|
|
22
22
|
|
|
23
23
|
- 🧭 **Cross-repository CAP tracing** — starts from a repo, service, operation path, operation name, or handler and follows the indexed flow across workspace boundaries
|
|
24
|
-
- 🧩 **Static CAP/CDS indexing** — extracts services, actions, functions, events, handler classes, decorator metadata, handler registrations,
|
|
24
|
+
- 🧩 **Static CAP/CDS indexing** — extracts services, actions, functions, events, handler classes, decorator metadata, handler registrations, executable symbols, local helper calls, and package-level `cds.requires`
|
|
25
25
|
- 🔗 **Service-to-service linking** — resolves `cds.connect.to(...)`, `remote.send(...)`, `cds.services.*` style calls, helper package imports, dynamic candidates, and unresolved evidence into graph edges
|
|
26
26
|
- 🗄️ **SQLite-backed workspace cache** — stores deterministic facts under `.service-flow/service-flow.db` so large workspaces can be queried repeatedly without reparsing everything
|
|
27
27
|
- 🧠 **Dynamic edge support** — preserves parameterized destinations and service paths such as `svc_${objectCode}_process`, then lets trace and graph commands apply runtime `--var key=value` values that can turn dynamic candidates into effective traversable operation edges
|
|
@@ -59,7 +59,7 @@ npm install @saptools/service-flow
|
|
|
59
59
|
- Repository selectors on list, trace, graph, and inspect commands narrow scope. Unknown selectors return empty machine-readable diagnostics instead of falling back to the whole workspace.
|
|
60
60
|
- Helper-package dependency edges prefer exact indexed package names. Duplicate package-name candidates are persisted as ambiguous evidence rather than silently selecting one repository.
|
|
61
61
|
- Handler registration parsing is AST-based for common `createCombinedHandler({ handler: ... })` forms: direct arrays, arrays assembled with spreads, non-`handlers` array names, aliased class imports, default-imported arrays, named exported arrays, and safe relative re-exports. Class-level rows keep registration file/line and import evidence.
|
|
62
|
-
- Implementation edges require both operation compatibility and registration evidence. Same-repository registrations do not need a self-dependency edge; cross-package matches use registration or handler-package dependencies on the model package. Duplicate strong candidates are stored as ambiguous implementation edges.
|
|
62
|
+
- Implementation edges require both operation compatibility and registration evidence. Decorator operation signals are stronger than method-name fallback; common generated names such as `FuncGetConfiguration` and `ActionGetConfiguration` are normalized before comparison, and a contradictory decorator rejects the candidate even when the TypeScript method name collides. Same-repository registrations do not need a self-dependency edge; cross-package matches use registration or handler-package dependencies on the model package. Duplicate strong candidates are stored as ambiguous implementation edges.
|
|
63
63
|
- Traces render persisted `OPERATION_IMPLEMENTED_BY_HANDLER` hops after static or runtime remote operation resolution, including terminal handler nodes and ambiguous or unresolved implementation evidence when traversal cannot continue.
|
|
64
64
|
- Repository fingerprints include source content, package name/version, dependencies and devDependencies, scripts, normalized `cds.requires` (including nested credentials), package file content, and the analyzer version. Metadata-only changes therefore trigger reindexing.
|
|
65
65
|
- Index publication is designed around the last-good snapshot: failed parse or persistence attempts are recorded as diagnostics and must not be mixed with older graph facts. After indexing changes, relink before relying on graph/trace output; doctor reports stale or inconsistent stores where detectable.
|
|
@@ -147,6 +147,14 @@ service-flow link --workspace /path/to/workspace --force
|
|
|
147
147
|
Trace one starting point and render table, JSON, or Mermaid output. Trace now
|
|
148
148
|
walks linked `graph_edges`, so a resolved remote operation is followed into the
|
|
149
149
|
target handler up to `--depth` instead of showing only calls in the first file.
|
|
150
|
+
|
|
151
|
+
### Symbol-scoped helper traversal
|
|
152
|
+
|
|
153
|
+
`service-flow trace` starts from the selected handler method symbol, renders outbound calls owned by that symbol, and follows conservative local helper-call facts. Supported helper edges include same-file functions, `this.method()` calls, and exactly mapped relative imports/exports that resolve to an indexed executable symbol. Calls from unrelated functions in the same source file are not included merely because the file path matches.
|
|
154
|
+
|
|
155
|
+
Local CAP calls through `cds.services.<Service>.<operation>()`, bracket service lookups, and simple aliases are indexed as local operation calls. Linking stays within the same repository by default and matches the target operation by exact qualified CDS service name, exact simple service name, exact service path, or an unambiguous service-path suffix. Entity accessors such as `cds.services.db.entities(...)` are treated as entity metadata access, not operation calls.
|
|
156
|
+
|
|
157
|
+
Conservative local symbol traversal intentionally excludes decorators, built-ins such as `JSON.parse`, collection methods, third-party APIs, and arbitrary property chains unless the callee can plausibly resolve to an indexed local symbol. Named export lists such as `export { loadTemplate as publicLoadTemplate }` are indexed with the public exported name so relative imports can resolve. One-level object-literal helpers are indexed as symbols named like `cacheHelper.getConfiguration`; nested object literals are not yet expanded beyond the first helper level. `parseGeneratedConstants` remains a public low-level parser export for callers that need it, but generated constants are not persisted as graph facts in this patch; linking uses the deterministic decorator normalizer described above.
|
|
150
158
|
JSON output includes typed nodes for calls, operations, database entities,
|
|
151
159
|
external destinations, and unresolved/dynamic candidates when edges exist.
|
|
152
160
|
|
|
@@ -166,7 +174,7 @@ service-flow trace --workspace /path/to/workspace --repo facade-service --operat
|
|
|
166
174
|
| `--service <path>` | Start from a CAP service path such as `/FacadeService` |
|
|
167
175
|
| `--path <operationPath>` | Start from an operation path such as `/doWork` |
|
|
168
176
|
| `--handler <name>` | Start from a handler class or handler-like selector |
|
|
169
|
-
| `--depth <n>` | Maximum
|
|
177
|
+
| `--depth <n>` | Maximum executable/service scope depth; defaults to `25`. Implementation hops are rendered at the current scope depth, while downstream handler bodies consume the next depth. The `step` field never exceeds the requested depth. |
|
|
170
178
|
| `--format <format>` | `table`, `json`, or `mermaid`; defaults to `table` |
|
|
171
179
|
| `--include-external` | Include external HTTP/destination edges in traversal output |
|
|
172
180
|
| `--include-db` | Include local DB query edges in traversal output |
|