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 clawbot2026-08-09 03:46:20 +02:00
Checked the public npm registry on 2026-09-23: the name quak is taken (another author's unrelated report builder, published since 2016), and @sneak/quak is free. By this issue's own recommendation that makes it Option B, publishing as @sneak/quak, which needs an npm account that owns the @sneak scope. So what is left for sneak is only B (publish as @sneak/quak) versus D (no registry; install from the git URL). Nothing is blocked until a tag.
Model: opus-5-5
Checked the public npm registry on 2026-09-23: the name `quak` is taken (another author's unrelated report builder, published since 2016), and `@sneak/quak` is free. By this issue's own recommendation that makes it Option B, publishing as `@sneak/quak`, which needs an npm account that owns the `@sneak` scope. So what is left for sneak is only B (publish as `@sneak/quak`) versus D (no registry; install from the git URL). Nothing is blocked until a tag.
Model: opus-5-5
Ruling from sneak: no. quak is not published to npm. The project uses no Microsoft services, which rules out npm, GitHub, Azure and VS Code.
The packaging work that depended on this is rescoped on #6.
Model: opus-5-5
Ruling from sneak: no. quak is not published to npm. The project uses no Microsoft services, which rules out npm, GitHub, Azure and VS Code.
The packaging work that depended on this is rescoped on https://git.eeqj.de/sneak/quak/issues/6.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Question
package.jsonis shaped like a publishable library —main,types,bin,files, and ahomepage/repositorypointing atgit.eeqj.de. But there is nopublishConfig, no.npmrc, and the namequakis 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.registryand a decision about where.Option D — do not publish at all; consumers install from the git URL.
Then
files,main,typesandbinare still worth getting right (a git install stillruns
prepare), but no registry credentials or release workflow are needed, and the README'sGetting Started should show a git-URL install rather than implying an npm package.
Recommendation: Option A if
quakis available on npm, otherwise Option B. The libraryhalf 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.
Checked the public npm registry on 2026-09-23: the name
quakis taken (another author's unrelated report builder, published since 2016), and@sneak/quakis free. By this issue's own recommendation that makes it Option B, publishing as@sneak/quak, which needs an npm account that owns the@sneakscope. So what is left for sneak is only B (publish as@sneak/quak) versus D (no registry; install from the git URL). Nothing is blocked until a tag.Model: opus-5-5
no, we don't use any microsoft services. no npm, no github, no azure, no vs code.
Ruling from sneak: no. quak is not published to npm. The project uses no Microsoft services, which rules out npm, GitHub, Azure and VS Code.
The packaging work that depended on this is rescoped on #6.
Model: opus-5-5