@zerwiz/ymir 0.1.26 → 0.1.27
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +17 -0
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -1,4 +1,21 @@
|
|
|
1
1
|
|
|
2
|
+
## 2026-09-17 — the installer actually installs (the whole platform, then proves it)
|
|
3
|
+
|
|
4
|
+
- **Why pi.dev and opencode just work and Ymir did not.** They are one binary: JS only, no Electron, no build step, no services, no windows — and their `curl|sh` installer puts the command on PATH *and* runs onboarding. The npm path is the side door. Ymir is a platform: its install must place a CLI, four apps, their dependencies, four Electron runtimes (which npm gates), two SPA builds, desktop entries and icons, the services, and a home — eight things to go wrong, and npm fights half of them.
|
|
5
|
+
- **So the one-liner now finishes the job**, the way theirs does: it installs the command, then runs **the first setup**, then **proves what stands** and names the next door. `YMIR_SKIP_SETUP=1` installs the command alone, for anyone who wants the old behaviour.
|
|
6
|
+
- An installer that stops at a binary leaves the user with a tool that does nothing yet.
|
|
7
|
+
|
|
8
|
+
## 2026-09-17 — the one-liner the README promised, and it sets the PATH
|
|
9
|
+
|
|
10
|
+
- **`install.sh` did not exist.** The README's first door (\`curl -fsSL …/install.sh | bash\`) led nowhere — which is how a user on another machine ends up typing \`ymir\` in every combination and getting nothing.
|
|
11
|
+
- **It exists now, and it removes the whole class of failure:** a prefix the user owns (no \`sudo\`, no \`EACCES\`), the \`export PATH\` written into the shell's rc so it survives the session, and then it **proves the door** with \`ymir --version\` rather than promising it.
|
|
12
|
+
- The command was never missing from the package — the published tarball ships \`bin/ymir.js\` and declares \`bin: {ymir, ymir-install}\`. **The shell simply was not looking where npm put it**, and that is the most common "it does not work" in the Node ecosystem.
|
|
13
|
+
|
|
14
|
+
## 2026-09-17 — 0.1.26: published, and the vault door named
|
|
15
|
+
|
|
16
|
+
- **@zerwiz/ymir@0.1.26 is on the registry** — the latest main, published as `zerwiz`. The token was in the encrypted vault all along; `age` was missing from this machine, and `bin/hodd.sh emit` returns empty, so every reader reported the token absent. The door is the fix, not the key.
|
|
17
|
+
- **The bump clears the registry**: main carried 0.1.18 while the registry served 0.1.25 (other sessions published past main).
|
|
18
|
+
|
|
2
19
|
## 2026-09-17 — "ymir: command not found" is a PATH fault, and here is the cure
|
|
3
20
|
|
|
4
21
|
- **The command is installed; the shell is not looking.** The published manifest carries `bin: {ymir, ymir-install}`, so the file is there — in npm's global bin directory, which an ordinary Linux install puts under `~/.npm-global` and a shell profile often never adds.
|
package/package.json
CHANGED