Files
SoulStream/package.json
T
KeelrLeek 4179247203 build: strip the UTF-8 BOM that stopped both halves of the app starting
0.1.0-alpha.2 bumped three version strings with a tool that writes UTF-8
WITH a BOM, and committed it. Neither build survives that:

  package.json      vitefu JSON.parses the raw string, so `npm run dev`
                    exited instantly — "Unable to read package.json"
  tauri.conf.json   the Tauri build script failed with "expected value at
                    line 1 column 1"; cargo exit 101
  Cargo.toml        tolerated, but wrong

`require()` hides this. Node strips a BOM on require and JSON.parse does
not, so reading package.json from a REPL reports a perfectly good file
while both builds refuse it. Only the raw bytes show it: EF BB BF.

All 191 tracked files scanned. These three were the only ones affected,
and they are exactly the three 5682dfc touched. Stripped with Node rather
than PowerShell, whose default Out-File/Set-Content encoding is what wrote
them in the first place — the files are byte-identical but for the three
leading bytes.

Cargo.lock carries the 0.1.0-alpha.1 -> alpha.2 propagation the release
commit left behind in the working tree.
2026-07-30 07:39:30 -05:00

23 lines
528 B
JSON

{
"name": "soulstream",
"version": "0.1.0-alpha.2",
"type": "module",
"description": "SoulStream — music player, downloader and streamer for the Soulseek network",
"scripts": {
"dev": "vite",
"build": "vite build",
"tauri": "tauri",
"test": "node --test tests/preview/*.test.mjs"
},
"license": "ISC",
"devDependencies": {
"@sveltejs/vite-plugin-svelte": "^5",
"@tauri-apps/cli": "^2.11.2",
"svelte": "^5",
"vite": "^6"
},
"dependencies": {
"@tauri-apps/api": "^2"
}
}