Add traceAPIDependency debug utility for inspecting transitive API de… - #348
Conversation
e1c9382 to
7349567
Compare
…pendencies Exposes two new helpers on globalThis.repluggableAppDebug.utils: - traceAPIDependency(entryPoint, api): returns a DependencyTree showing every route through which the entry point transitively depends on the API, built in-place during DFS (no flat paths intermediate). - visualizeDependencyTree(tree): renders the tree as an ASCII diagram, with shared prefixes collapsed. Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
7349567 to
f06fdc1
Compare
itsh01
left a comment
There was a problem hiding this comment.
Looks good. See 2 minor comments
| entryPoints = [...addedShells.values()].map(x => x.entryPoint) | ||
| ) => getAPIOrEntryPointsDependencies(apisOrEntryPointsNames, entryPoints), | ||
| traceAPIDependency: (entryPointName: string, apiName: string): DependencyTree | null => | ||
| traceAPIDependency(entryPointName, apiName, [...getUnreadyEntryPoints(), ...[...addedShells.values()].map(x => x.entryPoint)]), |
There was a problem hiding this comment.
why not reuse getAllEntryPoints?
There was a problem hiding this comment.
It throws "not implemented" error in runtime
| getAPIOrEntryPointsDependencies( | ||
| apisOrEntryPointsNames: string[], | ||
| entryPoints?: EntryPoint[] | ||
| ): { entryPoints: EntryPoint[]; apis: AnySlotKey[] } | ||
| traceAPIDependency(entryPointName: string, apiName: string): DependencyTree | null |
There was a problem hiding this comment.
These public signatures are inconsistent with the rest of the API and also with themselves.
Did you expose (getAPIOrEntryPointsDependencies) in public signature on purpose (+ isn't it weird that someone would need to provide an entrypoints array for the debug tool, or is there a use-case you know of)?
Why do you need entryPointName instead of deriving it by searching the declarer of the API?
There was a problem hiding this comment.
I just added types. The implementation itself is already there, and it accepts a list of entryPoints. Not sure if there are real use cases for that
There was a problem hiding this comment.
EntryPointName is the starting point.
The goal is to visualize subtree of dependencies starting from this entry point to the specific API.
Use case: we have one entry point that we don't want to be dependant on the DocumentServicesAPI, because this entry point should be executed as early as possible (to show welcome screen). So adding documentServices even transitively will make it appear much later.
So this utility should make it easy to understand if provided entry point is dependant on the provided api, and if yes - visualise why exactly
…pendencies
Exposes two new helpers on globalThis.repluggableAppDebug.utils: