@glance-apps/sync 1.8.0 → 1.11.0

package/CHANGELOG.md

@@ -7,6 +7,299 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
 
 ## [Unreleased]
 
+## [1.11.0] - 2026-08-30
+
+**Should you take this release?** Yes if you use the GLANCEvault transport, and
+immediately if anything in your bundle writes to it on a timer. This release is
+the client-side answer to a 2026-08-30 incident in which an intent-cleanup loop
+in the dayGLANCE Obsidian plugin deleted rows that were already tombstones. The
+server re-tombstoned on every call — fresh seq, fresh SSE nudge — which put the
+row back above the caller's cursor and fed the loop its own output. It ran for
+hours and saturated the server's per-IP rate budget, and it was **invisible**:
+every delete was fire-and-forget behind a `.catch(() => {})`, so nothing failed
+loudly enough to notice. Two patches landed elsewhere (the plugin no longer
+deletes tombstones; the vault's `softDeleteRow` is now idempotent). This release
+adds the protection and the visibility **by construction**, so no caller has to
+remember them and no loop can be silent. No server changes: the wire contract is
+untouched.
+
+### Added
+
+- **The intents transport.** `intentsBatch(accountId, events)` and
+  `intentsList(accountId, { since, limit })` wrap the server's existing
+  `/intents/*` endpoints, so apps can drop their hand-rolled raw-fetch
+  transports and inherit this client's auth, error classification, brake and
+  meter. `intentsBatch` is insert-only server-side — a re-sent `eventId` is a
+  no-op — so retrying an ambiguous failure is safe by construction.
+  - **Pure transport**: the `envelope` is opaque here and is never decoded or
+    inspected. The codec, and the per-envelope key derivation it needs, stays
+    in `@glance-apps/intents`; this package carries the transport without
+    carrying the crypto.
+- **A device-wide request brake.** Any real 429 now pauses *every* vault
+  request in the bundle realm: 30s, doubling per burst to a 10-minute ceiling,
+  one arming per burst (a concurrent fan-out that all meets the limiter costs
+  one escalation step, not ten). While paused, calls fail fast — **before
+  touching the network** — with a `VaultError` carrying `status: 429`,
+  `code: 'RATE_LIMITED'` and `retryInMs`.
+  - It is at **module scope, not per client instance**, deliberately: the thing
+    it protects is shared by every client in the process (the server's per-IP
+    budget), so the state that models it belongs to the realm. A separately
+    bundled copy — the Obsidian plugin's, say — is its own realm, which is
+    correct: separate process, separate traffic.
+  - **Decay, never amnesty.** A 2xx releases the pause but only *halves* the
+    escalation memory (below the 30s base it drains to zero). This is the fix
+    for the earlier app-side brake, which reset escalation to zero on *any*
+    success: on a saturated shared budget an occasional cheap request slips
+    into a fresh limiter window and returns 200, and each lucky 200 wiped the
+    whole 30s→480s escalation and re-licensed full cadence. Halving keeps the
+    storm's level in memory — the next 429 re-arms at 2× what is left — while a
+    genuine recovery still drains to nothing in a few quiet successes.
+  - Reads: `isVaultRateLimited()` and `vaultBrakeStatus()`, for callers that
+    prefer to sit a whole cycle out pre-flight. Escape hatch:
+    `createVaultClient({ brake: false })` opts a client out of both the gate
+    and the arming.
+- **A budget meter.** Requests are counted per rolling minute and attributed by
+  method name. Crossing a soft threshold (default 300/min — half the server's
+  default per-IP budget, configurable) logs **one** line per window naming the
+  top contributors: `[vault] budget: 412 requests in the last minute (soft
+  limit 300) — top: intentsList 210, batch 130, deleteRow 72`. Visibility only;
+  it never throttles. Its whole argument is that it needs no theory about *why*
+  a loop is running, so the next storm is an attributed event on day one rather
+  than an afternoon of archaeology.
+- **A write-loop detector — the success-side signal.** Failure visibility
+  already existed; what was missing on the day was the signal for everything
+  "succeeding" pathologically. The client now keeps a bounded per-`entityId`
+  history across `batch` upserts and `deleteRow`, and warns loudly (once per id
+  per window) when four **redundant** writes to one id land inside ten minutes.
+  Diagnostic only — never a brake.
+  - A write is redundant when it cannot have changed the row's state from what
+    the previous write to that id left it. Three shapes qualify: a **polarity
+    flip** (the delete-and-resupply loop), a **repeat delete** (re-deleting a
+    row that is already a tombstone — the incident's own shape: same polarity
+    every time, no content at all), and an **identical-content rewrite**.
+  - **Fails open by construction**: the rule needs repeated events on the
+    *same* id, so a first sync, a large import, or a bulk cleanup deleting many
+    different ids — many ids, one event each — can never trigger it, however
+    large. A bounded retry of one failed delete does not reach the threshold
+    either.
+  - Both thresholds are tunable via `configureVaultDiagnostics`. Four redundant
+    writes means five events (upsert/delete/upsert/delete/upsert, or five
+    deletes of one tombstone), which no human edit pattern produces and every
+    delete/resupply or re-tombstone loop produces within seconds; ten minutes
+    is long enough to catch a loop running on a 60s sync cycle and short enough
+    that a week of ordinary edits never accumulates into it.
+- `getVaultStats()` returns all three in one read: brake status, the last
+  rolling minute of requests by method, and the current write-loop suspects.
+  `configureVaultDiagnostics(options)` tunes the visibility-only thresholds and
+  the log sink; `resetVaultDiagnostics()` clears everything (for tests).
+
+### Changed
+
+- Every `createVaultClient` method now passes through the brake and the meter.
+  The only behaviour change a healthy caller can observe is the new
+  `RATE_LIMITED` rejection while a window is open — and only after the server
+  has already answered a real 429.
+- A **429 arms the brake only when it is a rate-limiter hit**, never when it is
+  an over-quota rejection. The server uses 429 for both and they call for
+  opposite handling: a limiter hit means "stop asking for a while" (exactly
+  what the brake does), while a quota rejection means the account is full,
+  clears only when an operator acts, and already has its own self-resuming
+  window in the DB engine. Gating on it would hide `QUOTA_EXCEEDED` and its
+  descriptor behind `RATE_LIMITED` and leave apps unable to render "X of Y
+  used". The quota shape is recognised as narrowly as before, so anything that
+  is not unmistakably a quota body is treated as a limiter hit.
+
+### Notes
+
+- **Not gated**: `fetchVaultHealth` and `enrollVaultDevice`. Both are
+  pre-credential, user-initiated, one-shot calls — `/healthz` is the
+  unauthenticated probe you reach for *while* diagnosing a stuck client, and
+  refusing it during a braked window would take away the diagnostic just when
+  it is wanted.
+- **For lastGLANCE / lifeGLANCE**: safe to take at leisure (semver-minor).
+  During a braked window, client calls fail fast with `VaultError { status:
+  429, code: 'RATE_LIMITED' }` instead of hitting the wire; any ladder that
+  already treats a real 429 as transient — they all do — handles it unchanged.
+  The meter and the write-loop warnings come along for free.
+- An AES-GCM envelope carries a fresh random IV, so identical plaintext does
+  not produce an identical envelope: for encrypted payloads it is the polarity
+  flip that fires the detector, and the identical-content rule covers plaintext
+  and deterministic payloads.
+
+## [1.10.0] - 2026-08-01
+
+**Should you take this release?** Yes, for any deployment using the database
+(GLANCEvault) transport. Until now the DB sync engine had **no backoff of any
+kind**: on a persistent failure it re-sent the same request on every cycle,
+forever, at whatever rate the app polls. A server that was down, a device
+offline, a wrong token — all of them produced an unbounded request loop. This
+release adds the backoff the file tier has always had, and fixes two related
+defects found alongside it. The file-tier (WebDAV) engine is untouched.
+
+### Fixed
+
+- **The DB engine no longer hammers a failing server.** Both directions now
+  back off: 30s doubling to a 15-minute cap for pushes and a 5-minute cap for
+  pulls, with a flat one hour on an authentication failure — the file tier's
+  numbers, escalation curve and reset rule. Any success resets the window and
+  its strike count. A window only ever **delays**: the next ordinary cycle
+  after it expires probes again, with no user action and no restart, and
+  dirty rows are never dropped — backoff changes *when* a push is retried,
+  never *whether* it is.
+  - Unlike the file tier's, the DB engine's backoff is **self-enforcing**: the
+    engine skips its own work when called too soon. (The file tier's is
+    advisory — nothing reads `uploadBackoffUntil` except its getter, so
+    honouring it is the app's job. That is exactly why the hammering was live
+    in every published version.) `getUploadBackoffUntil()` and
+    `getDownloadBackoffUntil()` are exposed with the same names and meaning as
+    the file tier's so one scheduler can treat both tiers alike, but honouring
+    them is now an optimisation rather than a duty.
+- **A failed pull no longer aborts the cycle.** 1.9.0 contained push failures
+  but left pull failures throwing past the device-cursor report. A pull error
+  is now captured the same way, so the cursor still reports on a cycle whose
+  pull failed.
+- **The pull cursor is persisted per page.** It was written only after the
+  whole pagination loop, so a failure on page 3 discarded the progress of
+  pages 1 and 2 — a large backlog on a flaky connection could re-download the
+  same pages indefinitely and never converge. Every row in a page reaches a
+  terminal outcome (applied, quarantined, or skipped as engine-reserved)
+  before the page ends, so the cursor may safely advance past each completed
+  page.
+- **A rejected credential surfacing from the push or pull now halts.** Once
+  the key is verified in-session, `ensureRootKey` makes no network call, so a
+  mid-session revocation is first seen by the push or the pull — and 1.9.0's
+  error capture routed those away from the halt path. They now reach exactly
+  the same halt logic as before; the halt itself, its identity rule, and the
+  `invalid credential` body match are unchanged.
+
+### Changed
+
+- **Over-quota suppression is now one case of the backoff ladder**, not a
+  parallel mechanism. Its behaviour is unchanged — same curve, same
+  in-memory lifetime, still surfacing `QUOTA_EXCEEDED` with its descriptor on
+  every suppressed cycle so apps can render "X of Y used" — but
+  `getQuotaState()` and `isQuotaSuppressed()` are now derived from the push
+  window rather than a separate variable.
+- **A shared-mode 401 is now delayed rather than retried immediately.** It
+  opens the one-hour auth window instead of being re-sent every cycle. It is
+  still not terminal and still not the credential halt: it self-resumes.
+- New: `getBackoffState()` returns `{ push, pull }` windows with `until`,
+  `reason` (`'quota' | 'auth' | 'transport'`), `code`, `strikes` and `since`.
+  The `reason` is what lets an app distinguish a one-hour auth backoff from a
+  thirty-second transport one without inferring it from the timestamp.
+- The cycle result gains `pullFailed`, `pullSkipped` and `pullErrorCode`,
+  mirroring the push fields added in 1.9.0.
+
+### Notes
+
+- **Classes that are never delayed**, deliberately: `PASSPHRASE_REQUIRED` and
+  `ACCOUNT_ID_REQUIRED` fire before any network call and clear the instant the
+  app supplies the value, so a window would make the app feel broken for 30
+  seconds after a user types their passphrase; and `CREDENTIAL_INVALID` is
+  owned by the (terminal) credential halt, so stacking a window on it would be
+  meaningless at best. `QUOTA_EXCEEDED` opens exactly one window, its own.
+- **For app integration — do not render backoff from the last `onError`
+  message.** On a cycle suppressed by a quiet (transport or auth) window, the
+  cycle's usual `onError(null, null, false)` reset still fires and nothing is
+  re-surfaced, so an app that remembers the last error string will see it
+  *cleared* while `onStatusChange` reads `'error'`. This is deliberate (quiet
+  windows report once; repeating every cycle is the noise this release
+  removes). Render standing backoff from `getBackoffState()` — `reason` plus
+  `until` gives "retrying in Xs" — and treat `onError` as an event stream, not
+  a status store. Quota windows are the exception and keep re-surfacing
+  `QUOTA_EXCEEDED` with the descriptor each cycle.
+- The cycle result now reports a superseded stale instance truthfully:
+  `{ superseded: true }` rather than `{ halted: true }`, matching
+  `isSuperseded()` / `isCredentialHalted()` whichever path the credential
+  rejection arrived by.
+- A healthy client is unaffected: no window is ever opened, no added latency,
+  and an identical request pattern.
+
+## [1.9.0] - 2026-08-01
+
+**Should you take this release?** Yes if you run, or might run, a GLANCEvault
+server with a row cap configured (`GLANCEVAULT_QUOTA_*`, server Phase 3.2).
+Also yes for the sync-reliability fix below, which applies to **every**
+deployment including shared mode and unconfigured servers: before this
+release, a failed push also cost you the pull, so a device whose writes were
+failing silently stopped receiving other devices' changes too. Nothing here
+changes behavior against a server with no quota configured, which is and will
+remain the common case.
+
+### Fixed
+
+- **A failed push no longer prevents the pull.** The DB sync cycle threw
+  straight from a push failure to its error handler, so `pullRemoteChanges`
+  and the device-cursor report never ran. A device that could not write — for
+  *any* reason: a transport blip, a 500, a server-side cap — also stopped
+  **reading**, and silently fell behind its peers. The push error is now
+  captured, the pull and cursor run regardless, and the error is reported
+  after. Applies to every transport failure, not just the quota case that
+  exposed it. Behavior on a fully successful cycle is unchanged.
+  - A cycle whose push failed but whose pull succeeded now returns
+    `{ applied, skipped, skippedEntityIds, pushFailed: true, pushErrorCode,
+    quota }` — the pull's own numbers are reported as usual, and `onError`
+    fires with the push error's code and `isHardStop: false`. `lastSynced` is
+    deliberately **not** advanced (the device is not fully in step), and the
+    dirty rows are retained for the next cycle exactly as before.
+- **A quota rejection is no longer mislabelled "update your server".** The key
+  verifier's establishing write is a net-new entity, so a fresh device on an
+  account at the row cap gets a 413 there — and every error on that path was
+  relabelled `VERIFIER_UNSUPPORTED` ("Your GLANCEvault server needs to be
+  updated to support key verification"), sending the user to fix a server
+  that is working correctly. `QUOTA_EXCEEDED` now passes through that
+  classifier, the same way `CREDENTIAL_INVALID` and the client-readiness
+  codes already did.
+
+### Added
+
+- **Over-quota handling for the reachable dimension (server Phase 3.2 /
+  client Phase 3.3).** A 413 or 429 carrying the server's quota body
+  (`{ error: "quota exceeded", quota, limit, used, requested }`) is now typed
+  as `QUOTA_EXCEEDED` and carries the parsed descriptor, so consumers no
+  longer have to substring-match an error message to tell a quota rejection
+  from any other failure.
+  - **Never a halt.** A quota condition is the opposite of a rejected
+    credential: it clears when the operator raises the limit or reclaim runs
+    — with **no client action at all** — so the engine keeps running.
+    `isHardStop` is always `false`, nothing is persisted, and there is no
+    recovery entry point and nothing to clear.
+  - **Bounded, self-resuming suppression** instead of retrying a doomed write
+    every cycle: after a rejection the engine skips the *write* for 30s,
+    doubling on repeat to a 15-minute cap (the file tier's backoff shape),
+    while pulls and cursor reports continue untouched. The next ordinary
+    cycle after the window probes again; a write that gets through clears the
+    state by itself. Raising the server limit is picked up with no restart,
+    no re-enrollment, and no user action.
+  - New state queries: `getQuotaState()` (the descriptor plus `since` /
+    `retryAt`, in memory only) and `isQuotaSuppressed()`.
+  - **Defensive parse.** A body earns the typed classification only with the
+    exact wording, a non-empty `quota` string, and three finite numbers.
+    A missing field, a non-JSON body, a 413 with no quota fields, the legacy
+    SSE `{"error":"too many connections for account"}` 429, or an older
+    server that never sends this shape all degrade to the generic
+    `VAULT_ERROR` handled before — never a throw, never a mis-classification.
+    An **unrecognised** `quota` dimension from a newer server is passed
+    through verbatim and still treated as a quota condition, since the remedy
+    is the same; render an unfamiliar dimension generically.
+
+### Notes
+
+- **Scope: `rows` is the only quota dimension this package can reach.** The
+  server enforces `storage` and `concurrent-uploads` at the blob path, and
+  `intents` at the intents route; this package has no blob path (media is
+  stripped at the adapter boundary) and no intents path (that is
+  `@glance-apps/intents`), and no SSE client. So "text syncs while media
+  fails" is not something this package can exercise. Handling for those
+  dimensions belongs with the media transport work that would call them, and
+  was deliberately not written here.
+- **Known gap, not fixed here:** the DB engine has no backoff of any kind
+  outside the quota window above. On a persistent write failure the same
+  dirty rows are re-pushed on every cycle indefinitely, where the file tier
+  has exponential backoff with an auth-failure escalation. This is a real
+  defect with a live blast radius and it wants its own change rather than a
+  corner of this one.
+
 ## [1.8.0] - 2026-07-31
 
 ### Added
@@ -62,6 +355,42 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   credential minted and then lost to a persistence failure is superseded by
   the next successful enrollment for the same `(accountId, deviceId)`.
 
+### Fixed
+
+- **Device cursors now report on installs that never configured a
+  `deviceId`, automatically on upgrade.** Such installs have never updated
+  their device cursor: the cursor step silently no-opped (`{updated:
+  false}`) whenever no `deviceId` was passed, so the server's tombstone GC
+  had no cursor for those devices. On upgrade, a device id is generated and
+  persisted (`{prefix}-device-id`) at engine construction, and cursor
+  reporting begins on the first completed sync cycle — **no app changes
+  required**; this applies to plain `createDbSyncEngine` construction, not
+  only the new connect flow, and identically in shared and per-account
+  mode. Installs that already pass an explicit `deviceId` are unaffected
+  and keep using it. Operator note: an install this fixes has no prior
+  cursor history, so the newly generated id strands nothing.
+  (This shipped in 1.7.0's device-identity work but 1.7.0 was never
+  published; it reaches consumers with this release.)
+
+### Upgrade notes
+
+Two behavior changes arrive with the fix above, without opt-in:
+
+- **Engine construction now touches localStorage.** `getOrCreateDeviceId`
+  reads and writes `{prefix}-device-id` at construction time; previously
+  construction deferred all localStorage access to cycle time. In an
+  environment without a `localStorage` global, construction now fails where
+  it previously succeeded and failed later at first sync. Theoretical for
+  browser and WebView hosts (all three GLANCE apps), but if construction
+  throws before any network activity, look here first.
+- **Injected `vaultClient` consumers see new `device()` calls.** An engine
+  constructed with `config.vaultClient` and no `deviceId` previously made
+  zero `device()` calls; it now makes one per cycle. A mock or bridge
+  client without a `device()` method will throw inside the cursor step —
+  swallowed and warned, never fatal — but the console warning is new and
+  recurring. Affects tests with mock clients and native shells that inject
+  a bridge client.
+
 ## [1.7.0] - 2026-07-31
 
 ### Added

package/README.md

@@ -158,6 +158,71 @@ Pass `encryptionEnabled: true` in the sync config object stored via `engine.setC
 | `createProviders(config)` | Creates cloud sync provider objects (`nextcloud`, `koofr`, `webdav`). |
 | `normalizeEtag(raw)` | Normalizes a raw ETag header value for If-Match use: strips a weak-validator prefix (`W/"abc"` → `"abc"`) and the content-coding suffixes some servers append inside the quotes (`"abc-gzip"` / `"abc-br"` → `"abc"`). Quotes are preserved; `null`/`undefined` pass through unchanged. |
 
+### GLANCEvault client
+
+| Export | Description |
+|--------|-------------|
+| `createVaultClient(config)` | HTTP client for a GLANCEvault server. `config` is `{ vaultUrl, vaultToken, fetchImpl?, brake? }`. Every method carries the Bearer token, classifies errors uniformly (`CREDENTIAL_INVALID`, `QUOTA_EXCEEDED`, `RATE_LIMITED`, else `VaultError` with `.status`), and passes through the module-scope brake and budget meter. |
+| `fetchVaultHealth(config)` | Unauthenticated `GET /healthz`. Returns `{ status, version, schemaVersion, authMode }`, with `authMode` normalized to `'shared'` on servers that predate the field. |
+| `enrollVaultDevice(config)` | Exchanges the admin-configured bootstrap secret for this device's own credential (`POST /enroll`). The credential is returned once and never again. |
+
+**`VaultClient` methods:**
+
+| Method | Description |
+|--------|-------------|
+| `batch(app, { accountId, rows })` | Upserts rows (`{ entityId, envelope, createdAt }`). Returns `{ written, maxSeq }`. |
+| `list(app, { accountId, since })` | One page of rows with `seq > since`. Returns `{ rows, hasMore }`. |
+| `getRow(app, entityId, accountId)` | Fetches one row; `null` on 404. |
+| `deleteRow(app, entityId, accountId, opts?)` | Soft-deletes a row. `opts.deletedAt` (epoch ms) stamps the tombstone for delete-vs-edit LWW. |
+| `device(app, { accountId, deviceId, lastSeenSeq })` | Updates this device's cursor. |
+| `getSalt(accountId)` / `putSalt(accountId, salt)` | Reads/registers the account root-key salt as a `Uint8Array` (first-write-wins). |
+| `intentsBatch(accountId, events)` | Appends intent events (`{ eventId, envelope, expiresAt }`) via `POST /intents/batch`. **Insert-only** — a re-sent `eventId` is a server no-op, so retrying an ambiguous failure is safe. Returns `{ written, maxSeq }`. |
+| `intentsList(accountId, { since, limit })` | One ascending page of non-expired intent events with `seq > since` via `GET /intents/list`. Returns `{ rows, hasMore }`; the server pages at 500. |
+
+The intents surface is **pure transport**: the `envelope` is opaque here and is
+never decoded or inspected. The codec (and the per-envelope key derivation it
+needs) stays in `@glance-apps/intents` — see `deriveKeyForSalt` above.
+
+### Request diagnostics
+
+One brake, one budget meter and one write-loop history per **bundle realm** —
+not per client instance. They model a resource every client in the process
+shares: the server's per-IP request budget. A separately bundled copy of this
+package (an Obsidian plugin, say) is its own realm, which is correct — it is a
+separate process with its own traffic.
+
+| Export | Description |
+|--------|-------------|
+| `isVaultRateLimited()` | `true` while the brake is engaged. For callers that would rather sit a whole cycle out pre-flight than fire a call and catch the rejection. |
+| `vaultBrakeStatus()` | `{ braked, until, memoryMs, retryInMs }`. |
+| `getVaultStats()` | The brake status, the last rolling minute of requests attributed by method, and the entityIds whose write history looks loop-shaped. |
+| `configureVaultDiagnostics(options?)` | Tunes the visibility-only thresholds (`softLimitPerMinute`, `loopTransitions`, `loopWindowMs`) and the log sink. The brake's curve is deliberately not configurable. |
+| `resetVaultDiagnostics()` | Clears all three and restores the defaults. For tests. |
+
+**The brake.** Any real 429 pauses *every* vault request in the realm: 30s,
+doubling per burst to a 10-minute ceiling, with one arming per burst. While
+paused, calls fail fast — before touching the network — with a `VaultError`
+carrying `status: 429`, `code: 'RATE_LIMITED'` and `retryInMs`, so retry
+ladders that already treat a real 429 as transient need no new code. A 2xx
+releases the pause but only **halves** the escalation memory, so the next 429
+re-arms at the storm's level; a genuine recovery drains to zero in a few quiet
+successes. An over-quota 429 (`QUOTA_EXCEEDED`) is not a limiter hit and does
+not arm it. `createVaultClient({ brake: false })` opts a client out of both the
+gate and the arming — an escape hatch for tests.
+
+**The budget meter and the write-loop detector** are visibility only; neither
+ever throttles. The meter logs one attributable line per minute when a realm
+crosses a soft threshold (default 300/min, half the server's default per-IP
+budget). The detector keeps a bounded per-`entityId` write history across
+`batch` upserts and `deleteRow` and warns once per id per window when four
+**redundant** writes to one id land inside ten minutes. A write is redundant
+when it cannot have changed the row's state from what the previous write to
+that id left it: a polarity flip, a **repeat delete** (re-deleting a row that
+is already a tombstone — the shape of the incident this was built for), or a
+rewrite with identical content. It fails open by construction: the rule needs
+repeated events on the *same* id, so a first sync, a large import, or a bulk
+cleanup deleting many different ids can never trigger it.
+
 ### Auto-backup
 
 | Export | Description |

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@glance-apps/sync",
-  "version": "1.8.0",
+  "version": "1.11.0",
   "license": "MIT",
   "type": "module",
   "main": "src/index.js",