The relative path was cut with a hardcoded "/", and skipDescendants(),
reached at node_modules, abandons the rest of the walk. Between them
the entrypoints were staged and nothing they import was.
npm is a .cmd shim, which CreateProcess declines, and there is no
/usr/bin/env to hand it to.
A comment is a last resort, and these were not one: section banners,
doc headers naming what the declaration below already names, and
notes saying in prose what the next line says in code.
What is left is what the code cannot show -- an ordering that matters,
a platform quirk, why the obvious way fails.
Rewriting the embedded agent on every run bumped the file
mtime and forced SwiftPM to recompile LumaCore and everything
downstream even when the content was identical.
Bundle compiler reads Agent/bundle.json describing outputs,
bundles, typings, and externals. Package install is driven by
Agent/package.json + Agent/package-lock.json (managed via
frida-pm), so the lockfile is the source of truth for resolved
versions.
@types/frida-gum and @types/node are embedded into
LumaTypings.swift at build time; the Resources d.ts is no
longer checked in. Editor profiles append both as extra libs.
Add a javaMethod anchor kind and the matching java-method scope
so the tracer can target JVM methods. Resolution uses
Java.enumerateMethods through the bridge; attachment replaces
each method's implementation and restores it on detach.
The bridge isn't bundled into our agent, since only one copy
can live in a process at a time. Instead it's marked external
so frida-compile leaves the imports as runtime lookups, and our
agent does `await import("frida-java-bridge")` on demand. If
the user hasn't installed the package via the Packages panel,
we surface a message pointing them there.
To let frida-compile honour the external, LumaBundleCompiler
grew a --external <name> flag that forwards to
BuildOptions.externals. Both the Xcode Run Script phase and the
GTK Makefile now pass --package [email protected] (for
TypeScript types) alongside --external frida-java-bridge (so
the runtime code isn't embedded).
Java resolves to no native address, so ProcessNode.resolve and
the instruction annotation map throw / skip rather than trying
to materialise one. The seed code for new Java hooks matches
frida-tools' pattern: log args via JSON.stringify.
Rename ProcessNode → ProcessNodeViewModel across all views
and update RuntimeEvent to wrap the LumaCore event type.
Views access core business logic through .core (evalInREPL,
symbolicate, resolve, anchor, readRemoteMemory, modules).
The ViewModel exposes Frida types directly (device, session,
script) and handles SwiftData persistence by subscribing to
the core's async event streams.
Lay the groundwork for a GTK/Adwaita frontend by extracting
shared infrastructure into a LumaCore Swift package. Agent
sources and LumaBundleCompiler move to top-level locations
so both the Xcode project and SPM can reference them.
New structure:
- Package.swift: root manifest with LumaCore lib + compiler
- Sources/LumaCore/: engine, persistence, models, and
platform-abstracted token store
- Sources/LumaBundleCompiler/: moved from LumaBundleCompiler/
- Agent/: moved from Luma/Agent/
- LumaGtk/: skeleton GTK app package
Ole André Vadla Ravnås