@tranquilload/core@0.1.9

Patch Changes

• 7872f26: Ship README.md and LICENSE in the published tarballs.

  Neither file had ever reached npm: both live at the repo root, and npm only
  force-includes them when they exist in the package directory itself — so the
  registry showed an empty description for both packages, and the MIT-licensed
  code shipped without its license text. A prepack hook now copies them from
  the root into each package at pack time, keeping a single source of truth.

  No runtime change: dist/ is byte-for-byte identical.

@tranquilload/core@0.1.8

Patch Changes

• cafa293: Ship only what consumers need: the published tarball is now dist/ + CHANGELOG.md + package.json, declared explicitly via a files field.

  Until now neither package declared files, so tarball contents were decided by whatever the packer chose to keep. Every release carried the full src/ tree (unit tests included), tsconfig.json, tsdown.config.ts, vitest.config.ts and even a stray .turbo/turbo-build.log. Install size drops accordingly.

  Nothing is lost for consumers. The .mjs.map / .cjs.map files embed complete sourcesContent, so stepping into library source in a debugger still works without src/ being shipped. No API change, no behaviour change — the runtime bytes under dist/ are identical.

  This also removes a real hazard: because dist/ is gitignored and the packer follows the ignore file in recent toolchains, an undeclared files field meant the published tarball could silently lose dist/ entirely — every export map entry pointing at a file absent from the package. Declaring files makes the published surface intentional rather than a side effect of .gitignore.

@tranquilload/core@0.1.10

Patch Changes

• 052491b: Add npm version badges and direct npm links for both packages to the README,
  plus a note that releases carry build provenance.

  Docs only — no code change. Released because the README now ships inside the
  published tarballs, so the npmjs.com pages would otherwise keep the previous
  version of it.

@tranquilload/adapters@0.1.9

Patch Changes

• 7872f26: Ship README.md and LICENSE in the published tarballs.

  Neither file had ever reached npm: both live at the repo root, and npm only
  force-includes them when they exist in the package directory itself — so the
  registry showed an empty description for both packages, and the MIT-licensed
  code shipped without its license text. A prepack hook now copies them from
  the root into each package at pack time, keeping a single source of truth.

  No runtime change: dist/ is byte-for-byte identical.

• Updated dependencies [7872f26]

  • @tranquilload/core@0.1.9

@tranquilload/adapters@0.1.8

Patch Changes

• cafa293: Ship only what consumers need: the published tarball is now dist/ + CHANGELOG.md + package.json, declared explicitly via a files field.

  Until now neither package declared files, so tarball contents were decided by whatever the packer chose to keep. Every release carried the full src/ tree (unit tests included), tsconfig.json, tsdown.config.ts, vitest.config.ts and even a stray .turbo/turbo-build.log. Install size drops accordingly.

  Nothing is lost for consumers. The .mjs.map / .cjs.map files embed complete sourcesContent, so stepping into library source in a debugger still works without src/ being shipped. No API change, no behaviour change — the runtime bytes under dist/ are identical.

  This also removes a real hazard: because dist/ is gitignored and the packer follows the ignore file in recent toolchains, an undeclared files field meant the published tarball could silently lose dist/ entirely — every export map entry pointing at a file absent from the package. Declaring files makes the published surface intentional rather than a side effect of .gitignore.

• Updated dependencies [cafa293]

  • @tranquilload/core@0.1.8

@tranquilload/adapters@0.1.10

Patch Changes

• 052491b: Add npm version badges and direct npm links for both packages to the README,
  plus a note that releases carry build provenance.

  Docs only — no code change. Released because the README now ships inside the
  published tarballs, so the npmjs.com pages would otherwise keep the previous
  version of it.

• Updated dependencies [052491b]

  • @tranquilload/core@0.1.10

@tranquilload/core@0.1.7

Patch Changes

• 4f1f268: Document the stale-reconcile trust boundary (Epic 13, Story 13.7 — spike resolved decline/document-only). When a resume's reconcileCompletedParts reports a part the backend has since garbage-collected (e.g. an S3 lifecycle rule expiring incomplete-multipart parts between the probe and /complete), the upload fails with CompleteUploadError at the complete phase.

  The core deliberately does not auto-detect and re-upload the missing part: the complete-phase error does not structurally identify which part is gone (parsing it would tie the protocol-agnostic core to S3 error strings), and the skipped part's bytes are already discarded with the source stream drained by the complete phase — so an in-band re-upload would require retaining every reconciled part in memory, defeating resume. Instead, the trust boundary is documented with two honest, caller-side remedies:

  • Verify before you skip — only report parts you have confirmed still exist in reconcileCompletedParts.
  • Re-probe and re-invoke — catch CompleteUploadError, re-probe, and re-run with a fresh source stream (the lib is idempotent across invocations).

  Docs-only: a new README "Reconciled-part integrity" section + a TSDoc note on reconcileCompletedParts. No new API, no behaviour change — the default upload path is byte-for-byte unchanged.

@tranquilload/adapters@0.1.6

Patch Changes

• ed96b80: Add an opt-in size-bounded auto-buffer to simpleHttpUpload (Epic 13, Story 13.6). For sources of a known size, set maxAutoBufferBytes (and contentLength) and the adapter chooses the transport up front — before the single-use stream is consumed — instead of forcing a manual per-environment bufferMode toggle:

  • contentLength <= maxAutoBufferBytes → buffered PUT/POST (HTTP/1.1-safe, works in every engine, no duplex: 'half').
  • contentLength > maxAutoBufferBytes → streamed PUT/POST (duplex: 'half', requires HTTP/2) — the large source is never held in memory.

  The decision is memory-safe by construction: maxAutoBufferBytes requires contentLength (the factory throws a TypeError rather than measure-then-buffer an unsized stream), and oversized sources stream rather than buffer. bufferMode: true still takes precedence (explicit mode wins). HTTP/2 capability detection is intentionally not attempted — the Fetch API exposes no negotiated-protocol signal in the browser, so a caller-supplied size threshold is the honest, deliverable knob.

  Default behaviour is byte-for-byte unchanged: with neither bufferMode nor maxAutoBufferBytes set, simpleHttpUpload streams with duplex: 'half' exactly as before.

@tranquilload/core@0.1.5

Patch Changes

• f7a1407: Event-stream flush-before-error: uploadMultipart().events (and uploadOnce().events) now flush every UploadEvent emitted before a failure or abort, instead of closing empty on the failure path. Events are enqueued live as they are produced; the typed UploadError still surfaces only via result (the events channel is split from the result channel, so the error is never masked). Observability on the failure path is no longer lost. Non-breaking: the success path is unchanged, and a failed/aborted upload still rejects result with the same typed error. (Story 13.5 — Observability. The optional ingest checksum half was carved out to a follow-up story.)
• 2655f1a: Document the ingest no-checksum trust boundary. The core deliberately does not checksum the bytes your pipeline produces — a digest of the uploaded bytes faithfully matches whatever a buggy compressor emitted, so it cannot detect that the compressor mangled its input. A new README section ("Ingest integrity") and a TSDoc note on uploadPart explain this and show the DIY path to server-verified wire integrity: every uploadPart(partNumber, chunk) hands you the exact post-pipeline bytes, so you can checksum chunk and forward a trailing checksum header (e.g. S3 x-amz-checksum-sha256) — no new library API required. Docs-only, no behaviour change. (Story 13.5b — Ingest Integrity Checksum; spike resolved to decline/document-only.)

@tranquilload/core@0.1.4

Patch Changes

• a95220c: Add an opt-in abortUpload teardown-cleanup callback to uploadMultipart (Epic 13, Story 13.3). When the upload is torn down after initiate has produced a uploadId but before the complete phase — i.e. an abort fires mid-part, or a part exhausts its retry budget — the lib now invokes abortUpload(uploadId) exactly once so you can clean up the server-side multipart (e.g. S3 AbortMultipartUpload) instead of orphaning it. The callback fires on any such teardown (abort or part-failure), guarded by upload phase rather than by inspecting the failure cause, keeping the core protocol-agnostic. It deliberately does not fire on a successful upload, before any uploadId exists, or during/after /complete — a late-stage /complete abort may already have landed server-side, so the lib documents a recovery contract (recover via the resolved resumeState by retrying completeUpload or reconcile-probing) rather than performing a possibly-destructive auto-abort. abortUpload errors are swallowed (best-effort) so a cleanup failure cannot mask the real upload error. Default behaviour (no abortUpload) is unchanged — the multipart is orphaned on teardown exactly as before.