interface LegacyUserAgent
Private

legacyCompat.userAgent()'s return shape — enough of Mojo::UserAgent's own chainable surface (->cookie_jar->add(...), ->max_redirects(n)->get(url)->result->body) to cover what the legacy plugin corpus actually calls, backed by fetch() instead of a real CPAN HTTP client. Not a general Mojo::UserAgent reimplementation — no proxy/auth/multipart support, no Mojo::Message-family object model, just the one GET/POST-with-cookies-and-redirects idiom every login/download plugin so far has used.

Properties

transactor: { name(value: string): void; }

$ua->transactor->name($value) — sets the default User-Agent header every subsequent get/post call on this instance sends.

A plain, JSON-serializable snapshot of this instance's cookie jar (the same live array the get/post/cookie_jar.add closures above mutate, not a copy) — every other property here is a function, which JSON.stringify silently drops, so a do_login-derived plugin's return ua; would otherwise cross handleRequest's writeLine (below) as an empty object. The host (lanrurugi-api::plugins::with_login_cookies) reads this off exec_login's result and threads it back into a later exec_metadata/exec_download/exec_script call as hostArgs.user_agent_cookies, which lanrurugi-plugin-converter's generated entry points rehydrate into a fresh userAgent() instance (see render.rs's render_user_agent_hydration_preamble) — a live object with closures can't itself cross that same JSON boundary, so this plain-array snapshot is what actually gets to do the traveling.

headers: Record<string, string>

A plain, JSON-serializable snapshot of every default header set on this instance via transactor/on so far — same "only plain data survives JSON.stringify" reasoning as cookies, just for header/token-based auth (e.g. Authorization: Key <api_key>) instead of cookie-based auth. The host reads this off exec_login's result and threads it back as hostArgs.user_agent_headers, rehydrated the same way user_agent_cookies is (issue #78/#93 — before this field existed, a login plugin authenticating via a header rather than a cookie had no way to pass that credential to a downstream metadata/download call at all: nhapiauth's Authorization header was silently dropped crossing this exact boundary).

Methods

on(
event: "start",
handler: (
) => void
): void

$ua->on(start => sub ($ua, $tx) {...}) — real Mojo::UserAgent fires this before every request; every real call site in the legacy plugin corpus only uses it to set one or more static headers via $tx->req->headers->header(...), never anything request-specific (e.g. inspecting $tx->req->url), so it's faithfully enough modeled by running handler once, immediately, against a synthetic tx whose header setter writes into this instance's default headers (applied to every get/post call from then on) rather than actually re-invoking it per request. Only the "start" event is recognized — legacy's other events (error/finish/etc.) have no real use in this corpus and aren't modeled.

get(
url: string,
headers?: Record<string, string>
): Promise<{ result: LegacyHttpResult; }>

headers, when given, are merged on top of this instance's own default headers (set via transactor/on) for this one request only — mirrors real Mojo::UserAgent's own ->get($url => {'Header-Name' => 'value'}) calling convention.

post(
url: string,
kind: "form" | "json",
data: Record<string, string> | Record<string, unknown>
): Promise<{ result: LegacyHttpResult; }>

kind mirrors Mojo::UserAgent's own ->post($url => form => {...}) / ->post($url => json => {...}) calling convention — form URL-encodes data as application/x-www-form-urlencoded (string values only, matching real HTML form semantics); json sends it as a application/json body (data may be any JSON-serializable value — verified against the one real json-kind call site in the corpus, which passes a nested object with an array value, not just flat strings).

Usage

import { type LegacyUserAgent } from "plugins/legacy-globals.d.ts";