feat: PWA with light/dark manifests and kimi web --pwa /web pwa#1929
feat: PWA with light/dark manifests and kimi web --pwa /web pwa#1929ceritium wants to merge 1 commit into
Conversation
🦋 Changeset detectedLatest commit: 602b945 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 602b945b30
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| ) | ||
| .option('--no-open', 'Do not open the web UI in the default browser.', true) | ||
| .option( | ||
| '--pwa', |
There was a problem hiding this comment.
Wire
--pwa before documenting it
When kimi web --pwa is passed, Commander records opts.pwa, but handleWebCommand never reads it and still calls deps.openUrl(...) with the same URL as the default path. In the advertised Chromium/app-window scenario, the flag is therefore a no-op and users get an ordinary browser tab despite the new help text promising otherwise.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
My first iteration did that; actually, I was doing --app instead of --pwa, but the PR was bigger, and I am not really interested in an "app for desktop", only making the web app more comfortable for phones.
| export async function handleWebCommand(host: SlashCommandHost): Promise<void> { | ||
| export async function handleWebCommand( | ||
| host: SlashCommandHost, | ||
| args = '', |
There was a problem hiding this comment.
/web pwa now reaches this handler, but the new args parameter is never inspected, so both the existing-server path and the start-new-server path behave exactly like /web; even unknown arguments are silently ignored. This makes the documented slash-command variant unable to request the PWA/app-window behavior.
Useful? React with 👍 / 👎.
Related Issue
No prior issue — this is a contribution to make the Kimi web UI installable as a PWA.
Problem
The web UI did not ship as an installable PWA, so users could not open it as a standalone app window. There was also no CLI/TUI flag to indicate the PWA preference.
What changed
vite-plugin-pwawithworkbox-windowinapps/kimi-web.boot.jsanduseAppearance.ts.kimi web --pwaand/web pwaflags. These are opt-in so the current default browser behavior is unchanged; they can become the default later if desired.Checklist