尚未检测到更新。GitHub 发布版本后会显示在这里。
个人 GitHub 账号下公开仓库的所有者可以登录并验证所有权,自行管理介绍,无需管理员批准。
登录并生成验证文件,在 30 分钟内将其提交到此仓库的默认分支。其他分支或分叉仓库中的文件无效。然后在下方检查文件,即可无需管理员批准直接管理项目。请保留文件以维持管理权限。
如需登录,将前往登录页面。登录后请回到此处,再次点击所选的验证按钮。
在项目文件夹中运行 /nomorevibe verify,即可验证所有权并自行管理介绍。
一分钟完成验证Free online karaoke with friends. Pick a song, start a party, and sing together in real-time with pitch scoring.
翻译准备中
取自仓库 README
正在加载完整 README。 以下为已保存的摘录。
Free online karaoke with friends. Pick a song, start a party, and sing together in real-time with pitch scoring.查看完整 README ↗Free online karaoke with friends. Pick a song, start a party, and sing together in real-time with pitch scoring.
/prerendered volume), legacy /{lang}/… and slug URLs get 301sRequires Bun >= 1.2.
bun install
bun run dev
Dev server starts on localhost:3001, proxying API requests to the backend at localhost:3000.
| Command | Description |
|---|---|
bun run dev | Start Vite dev server |
bun run build | Production build to build/ |
bun run preview | Preview production build locally |
bun run test | Run tests (Vitest) |
bun run test:e2e | Playwright end-to-end tests (needs the backend on :3000) |
bun run test:stress | Many-singer stress test, see below |
bun run test:stress puts a dozen singers into one party: real Chrome contexts
with a fake microphone, each running the whole pipeline (AudioWorklet → ONNX
pitch worker → WebSocket), the first one hosting. Every browser carries an
in-page monitor, and the run ends with a per-client table (frame rate, long
tasks, JS heap, notes in/out, latency) plus assertions that nobody
disconnected, everyone is on the scoreboard, the singers' notes reached the
host and the host stayed above MIN_FPS. Past eight singers the server puts
only eight on screen (three top scores pinned, five lanes rotating one per
lyric line), so from then on the host hears the lanes rather than everyone,
and the run prints who they were.
| Env | Default | Meaning |
|---|---|---|
REAL_SINGERS | 12 | Chrome contexts (incl. the host) |
BOT_SINGERS | 0 | extra synthetic singers driven from Bun over WebSocket (e2e/wsSinger.js), cheap enough for dozens |
STRESS_SECONDS | 30 | how long everyone sings |
MIN_FPS | 20 | host frame-rate threshold |
CPU_THROTTLE | 1 | DevTools-style CPU slowdown for every real browser: 4 ≈ mid-range phone, 6 ≈ an old low-end one |
Serve the production build for realistic numbers (bun run build && bunx vite preview;
the test reuses whatever is on :3001), because React's development runtime
alone dominates a profile. Emulating an old phone with a dozen singers:
REAL_SINGERS=1 BOT_SINGERS=11 CPU_THROTTLE=6 bun run test:stress.
Mind what you are measuring: every real context runs its own ONNX pitch
worker and YouTube player, so a dozen of them on one laptop saturate the CPU
and every client (host included) stalls — the run then prints a warning that
the host video stopped advancing. That measures the machine, not the app. To
measure the frontend's cost of rendering many singers, keep the real
browsers few and add bots: REAL_SINGERS=2 BOT_SINGERS=40 bun run test:stress.
docker build -t singspree-fe .
docker run -p 80:80 singspree-fe
Multi-stage build: Bun 1 Alpine for bun install --frozen-lockfile && bun run build, then Nginx Alpine to serve the static files. The build stage is deliberately not cached in CI -- installing takes about eight seconds, and caching it meant pulling a 577 MB node_modules layer out of the GitHub Actions cache first.
src/
components/ UI components (MusicBars, Lyrics, ShareCard, ...)
logic/ Pitch detection, mic input, lyrics parsing, WebSocket handling
pages/ Route pages (Entry, Party, Join, compliance pages)
i18n/locales/ 21 locale JSON files
index.css Tailwind v4 theme (neon-cyan, neon-purple, neon-magenta, neon-green)
MIT