Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Every daemon knows the latest Simlock version, and simlock status says when a newer one exists

Aperta
  • Qualcosa non va?
#837 0 commenti 0 reazioni 1 assegnatario Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@V3RON ci sta già lavorando.

Dal 22/10/2026.

  • #887 di @V3RON — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
57/100
Tipo di issue
Funzionalità
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
nodejs, typescript
Ambito
api, backend, cli

Direzione di ricerca

Start with #836 and its isNewerVersion rule, then read the listed contract schemas and operations, protocol, daemon main and dispatcher, gateway dispatcher and aggregate, config, CLI format, and the cited docs. Use the startDaemon seam in src/daemon/main.test.ts with FakeNpmCli and FakeClock, then exercise the CLI cases in src/cli/index.test.ts. Done means the specified daemon, gateway, failure, timing, config-off, and status output cases pass, and the configuration docs include update.check.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

task:ready

Part of #825.

Scope

Every daemon, worker or gateway, learns npm's latest Simlock version at start and every 24 h after. It reports it as status.get daemon.latestVersion and in the frozen daemon.update answer, and simlock status says when it's newer. update.check: false turns this off. It reads #836's isNewerVersion, the one "newer" rule. Shared values: update.check, the "newer" rule, the latestVersion field, the npm port, the protocol version.

In short

simlock status prints Simlock: 0.3.0 (0.4.0 available) once the daemon has seen a newer latest on npm. The check doesn't delay startup. The rule is "newer" by semver, comparing numbers first, so 0.10.0 beats 0.9.0. A release beats its own prereleases, so 0.4.0 beats 0.4.0-rc.2. Prereleases compare by their dot parts, numbers as numbers, so rc.10 beats rc.2.

flowchart LR
  T[start, off the start path; then every 24 h] -->|update.check true| V[NpmCli.view simlock version]
  V -->|ok| L[latestVersion]
  V -->|fails| K[keep last value, warn log]
  L --> S[status.get + daemon.update answer] --> P[simlock status line]
Running npm latest simlock status line
0.3.0 0.4.0 Simlock: 0.3.0 (0.4.0 available)
0.9.0 0.10.0 Simlock: 0.9.0 (0.10.0 available)
0.4.0-rc.2 0.4.0 Simlock: 0.4.0-rc.2 (0.4.0 available)
0.4.0 0.4.0 Simlock: 0.4.0
0.5.0-rc.1 0.4.0 Simlock: 0.5.0-rc.1
0.3.0 not known Simlock: 0.3.0

If this task goes wrong, a user would notice a missing or wrong "available" notice.

Technical spec

Facts
# Fact Source
F1 npm view simlock version prints npm's latest tag (0.2.0; npm view simlock dist-tags --json → {"latest":"0.2.0"}) ran 2026-10-21
F2 NodeNpmCli runs npm with the daemon's Node, in its data directory, with a 30 s limit on view #835 Modules touched
F3 A config key needs a type, a default and a validator entry in config.ts, plus a configSchema entry, or config.get drops it src/core/config.ts:336, 915, 1080; src/contract/schemas.ts:991; src/core/config.test.ts:2197
F4 compareVersions compares dotted numbers only and ignores prereleases; there's no semver dependency src/contract/os-range.ts:124-135; package.json
F5 startDaemon composes both roles and is driven in main.test.ts src/daemon/main.ts:182-186, 765; src/daemon/main.test.ts
F6 daemon start waits 20 s for the daemon to answer src/ports/daemon-launcher.ts:51
Modules touched

Searches: rg "readonly log:", rg "configSchema", rg "compareVersions" (os-range, its tests).

src/contract/schemas.ts and operations.ts (latestVersion filled in), src/contract/protocol.ts, src/daemon/version-check.ts (new), src/daemon/main.ts (both roles), src/daemon/dispatcher.ts, src/gateway/{dispatcher,aggregate}.ts, src/core/config.ts, src/cli/format.ts, website/src/content/docs/docs/reference/configuration.mdx, website/src/content/docs/docs/reference/cli.mdx, src/daemon/AGENTS.md.

Contract and event changes

This PR bumps the protocol by one, because latestVersion changes from always null to a value and the config schema gains a key. latestVersion is a string ≤ 64 matching #836's version pattern, or null. An npm answer that doesn't match keeps the last value. No events.

Failure modes
Call Outcome What happens Limit, counted from
NpmCli.view ok latestVersion set 30 s
NpmCli.view error, timeout or bad answer last value kept, warn log line 30 s

Nothing is stored. A restart checks again. The 24 h timer is cancelled in dispose, so a stopping daemon doesn't wait for it.

Rules in play
  • ADR 0042 §12: "at start and every 24 h after, unless update.check is false".
  • architecture rule 10: one "newer" rule, isNewerVersion from #836.
Tests

Seam: startDaemon (src/daemon/main.test.ts) with an injected FakeNpmCli and FakeClock, both roles. The CLI is driven through src/cli/index.test.ts.

  • Daemon runs the version check: at start without delaying ready, then after 24 h; newer found (latestVersion in status.get and the daemon.update query); npm fails or answers junk (last value kept); update.check: false (never runs, null); gateway role (same, read through status.get).
  • Operator reads simlock status with a known latest: the six rows of the table above.

Done when

  • pnpm test:changed passes (it runs the unit tests under src/daemon src/cli src/core src/contract).
  • CI's check job passes. website/src/content/docs/docs/reference/configuration.mdx has the update.check row, and reference/cli.mdx the simlock status notice.

Out of scope

  • The per-worker notice (#838) and the console (#839). Updating automatically.

Depends on

  • #836

Written by an agent.

Lingua principale
TypeScript
Stelle
20
Fork
2
Merge medio
8h 10m
PR unite (30g)
354

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di callstackincubator/simlock

Tutte le issue di callstackincubator/simlock

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.