refactor: create app-info file

[kantord]

No description provided.

[kantord]

@claude deep review please. make your report very succinct

[claude]

Claude finished @kantord's task in 1m 17s —— View job

---

Deep Review

• Gather context
• Read changed files
• Analyze and report

---

Summary: Good refactor — DEEP_LINK_PROTOCOL is now a single source of truth in common/app-info.ts, and the bash script is replaced with TypeScript. A few issues worth fixing:

---

Bugs

1. process.cwd() in generate-desktop.ts:6 — fragile path

const DESKTOP_FILE = path.join(process.cwd(), 'flatpak', ...)

This is called from forge.config.ts during the build hook. process.cwd() depends on where Forge is invoked — if it's not the project root, the file gets written to the wrong place. The install script uses import.meta.dirname to anchor to the project root; generate-desktop.ts should do the same:

const DESKTOP_FILE = path.join(import.meta.dirname, '..', 'flatpak', ...)

Fix this →

---

Security / Correctness

2. Unquoted paths in shell commands — install-deep-link-handler.ts:51,82,87

Paths are interpolated directly into shell strings without quoting. PROJECT_ROOT contains /home/runner/work/toolhive-studio/toolhive-studio which is fine today, but breaks on any path with spaces:

run(`dpkg-deb -x ${debFile} ${EXTRACT_DIR}`)          // line 51
run(`sed -i "s|^Exec=.*|Exec=${packagedBin} %U|" ${desktopFile}`)  // line 82
run(`sudo cp ${desktopFile} ${SYSTEM_APPLICATIONS_DIR}/`)  // line 87

The sed on line 82 also has a delimiter conflict risk: if packagedBin ever contains |, sed will misparse the substitution. The original shell script had the same issue, but it's worth fixing in the rewrite. Prefer spawnSync with argument arrays (like line 93 already does for xdg-mime) or wrap paths in quotes.

Fix this →

---

Minor

3. generate-desktop.ts — hardcoded app name vs enterprise overlay intent

app-info.ts comments say enterprise builds replace that file to change values. But generate-desktop.ts has hardcoded Name=ToolHive, Icon=com.stacklok.ToolHive, etc. If the enterprise overlay only changes DEEP_LINK_PROTOCOL, the generated .desktop file will still say ToolHive. Consider whether the app name/icon should also live in app-info.ts.

4. Re-export in deep-links.ts

deep-links.ts now imports and immediately re-exports DEEP_LINK_PROTOCOL. This is fine for backward compat, but any consumer that only uses DEEP_LINK_PROTOCOL should import from @common/app-info directly going forward (forge.config.ts already does this correctly).

---

[Copilot]

Pull request overview

This PR centralizes app identity constants (starting with the deep link protocol) into a new common/app-info.ts so packaging config and helper scripts can stay in sync and be overridden by an enterprise overlay.

Changes:

• Added common/app-info.ts and refactored deep-link protocol usage to import from it.
• Updated Electron Forge packaging config (protocol registration + rpm/deb mime types) and added a Linux .desktop generator to keep Flatpak metadata synchronized.
• Replaced the Linux deep-link handler install bash script with a TypeScript (tsx) script and updated TS config includes accordingly.

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
utils/generate-desktop.ts	Generates the Flatpak .desktop file using DEEP_LINK_PROTOCOL.
tsconfig.node.json	Expands Node TS project includes to cover scripts/ and common/.
scripts/install-deep-link-handler.ts	TS replacement for the deep-link handler installer (builds deb, extracts desktop file, installs it).
scripts/install-deep-link-handler.sh	Removed legacy bash implementation.
package.json	Switches the deeplink registration script to the new TS implementation.
forge.config.ts	Uses centralized DEEP_LINK_PROTOCOL and triggers desktop generation on Linux builds.
common/deep-links.ts	Re-exports DEEP_LINK_PROTOCOL from the new app-info module.
common/app-info.ts	New single source of truth for app identity constants (overlay-friendly).

[kantord]

@claude please do another round of review. i made some changes, addressing everythin you pointed out that was actually actionable/worth addressing + made some additional changes

[claude]

Claude finished @kantord's task in 2m 40s —— View job

---

Review (Round 2)

• Read changed files
• Analyze and report

---

Good fixes since round 1: import.meta.dirname replaces process.cwd(), writeIfChanged avoids dirty-tree rewrites, fs.mkdir with { recursive: true } is in place, FLATPAK_APP_ID is now in app-info.ts, and metainfo generation is a nice addition.

---

Bug (Critical): @app-info missing from Vite alias configs

main/src/ files now import directly from @app-info:

• main/src/deep-links/index.ts:9
• main/src/deep-links/parse.ts:4
• main/src/deep-links/squirrel.ts:4
• main/src/cli/symlink-manager.ts:26

But all three Vite configs only alias @common and @utils — not @app-info:

// main/vite.main.config.ts (same pattern in preload + renderer)
alias: {
  '@common': path.resolve(__dirname, '../common'),
  '@utils': path.resolve(__dirname, '../utils'),
  // ← @app-info missing
},

Vite doesn't read tsconfig.json paths automatically (no vite-tsconfig-paths plugin is used). TypeScript type-checking passes because tsconfig has the mapping, but the Vite bundle will fail to resolve these imports at build time.

Fix: add '@app-info': path.resolve(__dirname, '../app-info') to all three Vite configs (main/vite.main.config.ts, preload/vite.preload.config.ts, renderer/vite.renderer.config.ts).

Fix this →

---

Still unaddressed: Unquoted paths in install-deep-link-handler.ts

Lines 49, 51, 82, 87, 90 still interpolate paths directly into shell strings via run(). This was flagged in round 1 and again by Copilot. Paths are currently safe (no spaces), but the pattern is fragile. Node APIs (fs.rm, fs.mkdir, fs.copyFile) or spawnSync with arg arrays would be safer for the rm/mkdir/cp calls; the sed and dpkg-deb ones require shell or spawnSync with an arg array.

---

[samuv]

IDK, I feel this should live in common in any case, so we don’t have specific aliases.