ContractSpecContractSpec

Start with OSS

Back to changelog index

0.4.19

Jul 16, 2026 · 4 packages · 7 unique changes · 2 release entries

libs

This release affects the sharedLibs family.

Run contractspec connect adoption resolve --family sharedLibs to see how it impacts your project.

Release summaries

  • data-exchange-import-templates

    Add template-aware import mapping with column aliases, flexible value formatting, codec options, client review state, and server audit evidence.

    maintainer

    Maintainers can define reusable import templates that resolve incoming file columns through aliases, normalized labels, and SchemaModel fallback inference.

    integrator

    Integrators can accept partner CSV/JSON/XML layouts with localized number, boolean, date, JSON, split/join, currency, and percentage formatting before preview or execution.

    customer

    Import review screens can show matched columns, required gaps, formatting summaries, and ignored source columns before users execute an import.

  • data-exchange-stack

    Add a new SchemaModel-first data interchange stack with shared codecs, planning APIs, server adapters, client mapping surfaces, and a compatibility refresh for `@lssm-tech/lib.exporter`.

    maintainer

    Maintainers now have a dedicated data-interchange package family instead of the orphaned `lib.exporter` stub, with SchemaModel-driven planning in core, adapter-based execution on the server, and reusable mapping/review controllers on the client.

    integrator

    Integrators can profile CSV/JSON/XML payloads into normalized record batches, infer mappings against SchemaModels, preview and validate changes, and route execution through file, HTTP, SQL, or storage adapter families.

    customer

    Existing `@lssm-tech/lib.exporter` consumers keep the legacy CSV/XML payload API and gain a JSON wrapper, while new work can adopt the more robust data-exchange stack directly.

Deprecations

  • - `@lssm-tech/lib.exporter` remains as a compatibility shim; prefer `@lssm-tech/lib.data-exchange-core` for new import/export work.

Migration guide

  • Add templates to new import flows

    Existing explicit mappings continue to work; new flows can pass an import template to plan creation, dry-run, or execution APIs.

    When: When an import has a recommended column shape but users may upload partner-specific headers or localized values.

    1. Define a template with `defineDataExchangeTemplate` or the backwards-compatible `defineImportTemplate` alias.
    2. Add `sourceAliases` and `format` hints to template columns where partner files differ.
    3. Pass `template` to core plan creation or server dry-run/execute calls.
    4. Use the client controller model to show matched, unmatched, and ignored columns.

  • Prefer the new core codecs and planning APIs for new integrations

    Keep `lib.exporter` only for legacy payload callers; build new import/export flows on the new core/server/client package family.

    When: When implementing new interchange flows or connector-backed imports/exports.

    1. Use `@lssm-tech/lib.data-exchange-core` for normalized `RecordBatch`, mapping, preview, and reconciliation planning.
    2. Use `@lssm-tech/lib.data-exchange-server` for file, HTTP, SQL, or storage execution services.
    3. Use `@lssm-tech/lib.data-exchange-client` for shared mapping/review UI surfaces.

  • Keep legacy exporter callers on the compatibility shim

    The old payload shape remains valid, with CSV/XML preserved and JSON added.

    When: When an existing integration already depends on `toCsvGeneric` or `toXmlGeneric`.

    1. Keep the existing `CsvXmlExportPayload` shape.
    2. Use `toJsonGeneric(...)` when the same legacy payload now needs JSON output.
    3. Migrate to the new core package only when you are ready to adopt normalized `RecordBatch` flows.

Upgrade steps

  • Re-run focused package verification

    assisted

    The new stack spans new packages plus the legacy exporter shim.

    Packages: @lssm-tech/lib.data-exchange-core, @lssm-tech/lib.data-exchange-server, @lssm-tech/lib.data-exchange-client, @lssm-tech/lib.exporter

    1. Run the focused bun test suites for `data-exchange-core`, `data-exchange-server`, `data-exchange-client`, and `exporter`.
    2. Run targeted typechecks and lint checks for the same four packages.
    3. Treat `build:bundle` as the current build proof; if `contractspec-bun-build types` stalls, rely on the separate package typechecks until the build tool issue is fixed.

Unique release changes

  • - `@lssm-tech/lib.exporter` remains as a compatibility shim; prefer `@lssm-tech/lib.data-exchange-core` for new import/export work.

    4 packages · 4 occurrences

  • - Add a new SchemaModel-first data interchange stack with shared codecs, planning APIs, server adapters, client mapping surfaces, and a compatibility refresh for `@lssm-tech/lib.exporter`.

    4 packages · 4 occurrences

  • - Keep `lib.exporter` only for legacy payload callers; build new import/export flows on the new core/server/client package family.

    4 packages · 4 occurrences

  • - The new stack spans new packages plus the legacy exporter shim.

    4 packages · 4 occurrences

  • - The old payload shape remains valid, with CSV/XML preserved and JSON added.

    4 packages · 4 occurrences

  • - Add template-aware import mapping with column aliases, flexible value formatting, codec options, client review state, and server audit evidence.

    3 packages · 3 occurrences

  • - Existing explicit mappings continue to work; new flows can pass an import template to plan creation, dry-run, or execution APIs.

    3 packages · 3 occurrences

Impacted packages

  • @lssm-tech/lib.data-exchange-client

    Layer: libs · 5 changes

  • @lssm-tech/lib.data-exchange-core

    Layer: libs · 5 changes

  • @lssm-tech/lib.data-exchange-server

    Layer: libs · 5 changes

  • @lssm-tech/lib.exporter

    Layer: libs · 5 changes