Docs / Development

Submodules & Source Map

How the Git submodules and monorepo workspaces are divided, and where to read or change a given part of Vyline.

Four Git submodules

The following four paths reference external repositories. A normal checkout can fetch all of them with git clone --recurse-submodules.

Path	Repository	Responsibility
`Vyline/packages/protocol`	tqmane/vyline-api	LINE protocol, login, E2EE, RPC, domain facade
`Vyline/packages/plugin`	tqmane/vyline-plugin	plugin SDK / examples / permission model
`Vyline/packages/themes`	tqmane/vyline-theme	VyTheme types and presets
`tools`	tqmane/vyline-search	Desktop LINE version tracking, unpack, xref, and decompile tooling

Submodules are not the same as workspaces

Not everything under Vyline/packages/ is a submodule. The main monorepo also contains workspace packages such as line-types (vendored Thrift definitions), types / loose-types, cli / vyl / create-plugin, and ios-backup. “Four submodules” counts only the external repositories.

Protocol

This is the primary source tree for LINE communication behavior. The public API starts at src/index.ts, the feature-to-research map is src/modules.map.ts, and the RPC correspondence table is src/dictionary/rpcMap.ts.

Inside Protocol	Role
`stack/`	Low-level Thrift RPC, Talk/Login communication
`src/login/`	QR/Email/Token login, Desktop transport patches, E2EE identity
`src/domain/`	Backend-facing Profile/Contacts/Chat/Talk facade
`src/dictionary/rpcMap.ts`	Desktop evidence → path → stack/domain/backend mapping
`src/modules.map.ts`	Feature-level related source and Desktop search hints
`src/updater/` / `src/desktop/`	Desktop profile and version/header update tracking

Backend consumes @vyline/protocol as a workspace dependency. A standalone Protocol checkout does not include sibling workspace dependencies such as @vyline/line-types and @vyline/loose-types, so development normally happens from this monorepo.

Plugin

The submodule contains the SDK and examples; the main repository Backend owns the runtime. @vyline/plugin-sdk provides definePlugin, manifest and permission types, and context/event contracts.

Vyline/packages/plugin (submodule)
  └─ sdk: public contract / examples
          ↓ workspace import
Vyline/backend/src/line/pluginManager.ts
  ├─ discover / enabled state
  └─ pluginRuntime.ts
       ├─ activate / deactivate
       ├─ permission-aware context
       └─ handler isolation

The existence of a permission string does not mean every capability is implemented in the runtime. Check both the SDK types and the Backend context exposed at runtime.

Themes

The themes submodule exports THEME_PRESETS and the VyTheme type. A theme is a full token set for surfaces, sidebar, messages, radii, chat backgrounds, patterns, and related values, not just an accent color. The Frontend consumes the theme contract rather than hard-coding individual presets.

Tools

These tools are used to verify Protocol assumptions after Desktop LINE updates. They cover version checks/updates, Themida unpacking, string/xref search, and Ghidra decompile assistance. They are research tools used to decide implementation changes; they are not runtime dependencies bundled into the production Vyline server.

Root script	Purpose
`bun run vyline:check`	Compare installed, running, and latest versions
`bun run vyline:update`	Update Desktop LINE
`bun run vyline:unpack`	Unpack the selected LINE.exe
`bun run vyline:find-native -- <name>`	Trace a native implementation through string/xref/decompile paths
`bun run vyline:delta`	Narrow update differences using the Protocol feature map

Choosing the repository to change

Change	Repository to commit	Required in the main repository
LINE RPC/E2EE/login	`tqmane/vyline-api`	Update submodule pointer + integration test
Plugin SDK	`tqmane/vyline-plugin`	Check Backend runtime compatibility + update pointer
Theme preset/type	`tqmane/vyline-theme`	Verify rendering in Frontend + update pointer
Desktop analysis tool	`tqmane/vyline-search`	Verify through root scripts + update pointer
Backend/UI/storage	Main `tqmane/vyline`	Normal workspace change

Editing a submodule checkout does not make the main repository reference the new commit. Commit inside the submodule first, then explicitly update the submodule pointer in the main repository.

Clone and update

git clone --recurse-submodules https://github.com/tqmane/vyline.git
cd vyline
git submodule status

If an existing clone has empty submodule directories:

git submodule update --init --recursive

Use git submodule status to inspect the referenced commits and git status --short to inspect changes. Running git pull only inside a submodule does not update the reproducible commit reference stored by the main repository.