Decision needed: does quak publish to npm? #16

New Issue

clawbot · 2026-08-09T03:46:20+02:00

clawbot commented

2026-08-09 03:46:20 +02:00

Question

package.json is shaped like a publishable library — main, types, bin, files, and a
homepage/repository pointing at git.eeqj.de. But there is no publishConfig, no
.npmrc, and the name quak is unscoped.

Before 1.0.0 I need to know which of these you want, because it changes the packaging work:

Option A — publish to the public npm registry as quak (recommended if the name is free).
The README's import { Client } from "quak" example then actually works for a stranger.
Requires the name to be available, an npm account/token, and a publishConfig.

Option B — publish to a scoped name (@sneak/quak) on the public registry.
Immune to name squatting. The README import line changes.

Option C — publish to a private/self-hosted registry.
Needs publishConfig.registry and a decision about where.

Option D — do not publish at all; consumers install from the git URL.
Then files, main, types and bin are still worth getting right (a git install still
runs prepare), but no registry credentials or release workflow are needed, and the README's
Getting Started should show a git-URL install rather than implying an npm package.

Recommendation: Option A if quak is available on npm, otherwise Option B. The library
half of this project is only useful to other people if it is installable by name, and that is
the stated point of splitting library from CLI.

No work is blocked on this today — the packaging-metadata issue is correct under every option.
It becomes blocking at tag time.

## Question `package.json` is shaped like a publishable library — `main`, `types`, `bin`, `files`, and a `homepage`/`repository` pointing at `git.eeqj.de`. But there is no `publishConfig`, no `.npmrc`, and the name `quak` is unscoped. Before 1.0.0 I need to know which of these you want, because it changes the packaging work: **Option A — publish to the public npm registry as `quak` (recommended if the name is free).** The README's `import { Client } from "quak"` example then actually works for a stranger. Requires the name to be available, an npm account/token, and a `publishConfig`. **Option B — publish to a scoped name (`@sneak/quak`) on the public registry.** Immune to name squatting. The README import line changes. **Option C — publish to a private/self-hosted registry.** Needs `publishConfig.registry` and a decision about where. **Option D — do not publish at all; consumers install from the git URL.** Then `files`, `main`, `types` and `bin` are still worth getting right (a git install still runs `prepare`), but no registry credentials or release workflow are needed, and the README's Getting Started should show a git-URL install rather than implying an npm package. **Recommendation: Option A if `quak` is available on npm, otherwise Option B.** The library half of this project is only useful to other people if it is installable by name, and that is the stated point of splitting library from CLI. No work is blocked on this today — the packaging-metadata issue is correct under every option. It becomes blocking at tag time.

sneak was assigned by clawbot

2026-08-09 03:46:20 +02:00

clawbot referenced this issue

2026-08-09 03:47:27 +02:00

Tag v1.0.0 #15

clawbot referenced this issue

2026-08-09 16:10:10 +02:00

Decision needed: account credentials committed in `test/integration/live-login.ts` #14

Sign in to join this conversation.