fix: preserve deployment paths across environments

[wsxiaolin]

No description provided.

[github-actions]

🤖 Codex-Style Code Review by OpenCode

💡 This is an automated advisory review. It is non-blocking and does not affect merge requirements.

Let me gather some context on the getPath utility, the router, and the loading CSS to provide a thorough review.
Here is the full PR review:

---

PR Review: Hash-based routing support for GitHub Pages deployment

Overview

This PR refactors the app to properly support deployment on GitHub Pages with hash-based routing. The core change is moving from hardcoded /assets/... paths to dynamic getPath('/@base/assets/...') calls, alongside a new 404.html SPA fallback and fixes to the router's dynamic import error recovery.

---

🔴 Blocking

1. public/404.html:6-10 — Fragile GitHub Pages detection

const isProjectPage =
  window.location.hostname.endsWith('.github.io') && parts[0] === 'plweb2'

Two issues:

• The repo name plweb2 is hardcoded. If the repo is renamed or forked, this silently breaks.
• Custom domains on GitHub Pages won't match .github.io, so the sub-path prefix will be dropped, causing incorrect redirects (e.g., /#route instead of /custom-path/#route).

Fix: Derive the base path from <base> tag or a build-time constant rather than heuristics. At minimum, inject import.meta.env.BASE_URL into the HTML at build time, or use a script that checks <base href="..."> in the DOM.

---

🟡 Important

2. ApiErrorDialog.vue — icon prop removal may break callers

The icon prop and its default /assets/messages/Message-Default.png were removed. The template already didn't render an icon (<template> shows only title, message, and buttons), so the prop was dead code. However, verify that no callers pass icon as a prop:
Good — no callers pass icon, confirming safe removal. Marking this resolved.

3. public/404.html:14 — window.location.hash collision risk

The redirect appends the existing window.location.hash after constructing the new hash URL:

`${basePath}#${routePath}${window.location.search}${window.location.hash}`

If the 404 page was reached via a URL that already had a fragment (e.g., /plweb2#existing-fragment), the result would be #/route#existing-fragment, which is invalid. Consider stripping the original hash or using URL constructor to avoid double-hash issues.

---

🟢 Nitpicks / Suggestions

4. wortList.vue — Scoped .loading CSS removal is correct but the component still references loading.value on line 127

The removed CSS was unused since the component doesn't have a .loading div in its template (the .loading class is used only in parent views via the shared loading.css). Removing it is correct. The loading.value = false on line 127 appears to be a leftover state variable — consider a follow-up cleanup if it's no longer read anywhere.

5. BlackHole.vue / Home.vue — Inline backgroundImage duplication

Both views now set backgroundImage inline with the same value:

:style="{ backgroundImage: `url(${getPath('/@base/assets/messages/Message-Default.png')})` }"

This duplicates the URL string across files. Consider exposing a shared CSS variable or a computed CSS class from a composable to keep it DRY. Alternatively, define a CSS class with a CSS custom property and set it via inline style:

.loading {
  background-image: var(--loading-bg);
}

---

✅ What's good

• Consistent pattern: All 8 image references across views/components are updated uniformly to getPath, making the asset resolution strategy predictable and easy to audit.
• Router error recovery fix (router/index.ts:124-127): Using import.meta.env.BASE_URL instead of hardcoding / makes routing respectful of deployment sub-paths. Switching to window.location.replace (vs href =) avoids adding a history entry for the failed navigation.
• loading.css cleanup: Removing the hardcoded background-image from the shared CSS was essential — it couldn't resolve through getPath() from a static CSS file. Moving it to inline styles is the pragmatic solution.
• No dead imports or unused variables detected across the changed files.

---

Summary

Severity	Count
🔴 Blocking	1
🟡 Important	1
🟢 Nit	2

The PR is well-structured and clearly motivated. The blocking issue (fragile GitHub Pages detection in 404.html) should be addressed before merging; the rest are minor. Overall, this is a solid refactoring that correctly enables GitHub Pages deployment with hash-based routing.