Skip to content

Client API 4.4.28 — dependency bumps, ESM build output, and test/tooling updates

Choose a tag to compare

released this 23 Aug 19:22
· 53 commits to working since this release

This release finalizes the 4.4.x patch cycle for the client API package and consolidates a set of dependency updates, build / test configuration changes, and housekeeping edits to package files. The primary goals reflected in the changes are: publishing version 4.4.28, aligning Fjell subpackage patch versions, moving the package to an ESM-oriented build output, and improving the Node test environment and Vitest configuration. These changes affect package metadata, runtime and dev dependencies, test setup, and compiler output — developers should read the relevant sections below to understand upgrade impact and any adjustments required for local development or CI.

New Features

  • ESM-style packaging and declarations
    • package.json now uses ESM-style fields: module and exports are used in place of legacy main/browser/type entries. This change supports native ES module consumers and modern bundlers.
    • Type declarations are emitted via a types entry pointing to ./dist/index.d.ts (see tsconfig and build outputs).
    • Affects: package.json, tsconfig.json, build output (dist/).

Improvements

  • Published package version changes

    • Release published as 4.4.28 (package.json updated from development suffix to stable: 4.4.28), and development cycle bumps are included for previous release transitions (4.4.27, 4.4.26, etc.).
    • Development cycles are visible in intermediate commits that set -dev.0 suffixes when beginning new cycles; final state is 4.4.28.
  • Dependency alignment and patch bumps

    • Runtime dependencies updated to newer patch versions to align with upstream Fjell packages:
      • @fjell/registry moved from ^4.4.32 -> ^4.4.33 (also updated in package-lock.json with resolved tarball URL and checksum normalization).
      • Several prior bumps in the release series updated other Fjell packages across earlier commits (e.g. @fjell/core, @fjell/http-api, @fjell/logging) to keep patch-level compatibility across the monorepo.
    • deepmerge remains a runtime dependency.
    • These dependency updates reduce mismatch risk with other Fjell packages and ensure expected runtime behavior when used alongside other Fjell modules.
  • ESLint and dev-tooling alignment

    • Dev tooling entries updated to ensure current ESLint rule sets are used (e.g. bump of @fjell/eslint-config in prior commits). This affects linting and CI checks but should not change runtime behavior.

Bug Fixes

  • package.json formatting and newline normalization
    • Several commits normalized formatting and file endings (ensured trailing newline, removed extra blank lines in dependencies blocks) to maintain consistency and prevent diff noise when publishing.
    • package-lock.json entries for @fjell/registry had duplicate/extra blank lines removed and integrity/resolved fields updated to match the bumped patch version.

Refactoring

  • TypeScript and build configuration simplification
    • tsconfig.json was simplified and aligned for ESM output:
      • Enabled sourceMap, declaration: true, outDir: "dist".
      • Removed rootDir, esModuleInterop, and certain explicit moduleResolution entries to streamline compilerOptions for ES2022 target/module settings.
      • Excluded examples, tests, dist, and node_modules from compilation to focus on src.
    • These changes are intended to produce consistent dist/ artifacts suitable for ES module consumption.

Documentation Updates

  • docs/package.json script pinning
    • The docs copy-docs script was changed to use a local node module path instead of npx, i.e. node node_modules/@fjell/docs-template/dist/scripts/copy-docs.js. This pins the script resolution and avoids npx variance in CI or local runs.

Developer Experience

  • Test environment polyfills and test config changes

    • Tests now polyfill Node test globals for fetch/FormData/Blob/File using undici and Node buffer where necessary (see changes in tests/setup.ts).
    • Removed a large global mock for @fjell/logging in favor of more targeted test setup.
    • Added vitest-fetch-mock to enable fetch mocking in Vitest.
  • Vitest configuration simplification

    • vitest.config.ts was simplified:
      • Added triple-slash reference types for Vitest and enabled globals: true.
      • Removed many explicit settings (environment, setupFiles, testTimeout, detailed coverage include/exclude entries) to simplify configuration surface and rely on sensible defaults.
      • Converted to a consistent defineConfig export.
    • Impact: local test runs may see slightly different default timeouts / coverage behavior; review Vitest config if CI relies on previous explicit coverage filters.

Testing Improvements

  • Better test polyfills for Node environment

    • Tests/setup.ts now explicitly polyfills web-like globals making the test environment closer to browser semantics where tests expect fetch/FormData/Blob/File.
    • This reduces the need for brittle mocks and makes tests more stable when run under Node.
  • Removed heavy global mocks

    • The large global mock previously present for @fjell/logging was removed, favoring smaller, per-test mocks or the actual logging implementation in tests.

Configuration Changes

  • package.json and package-lock.json housekeeping
    • Repeated updates across the release series touched package.json and package-lock.json to:
      • Bump package version from development to release artifacts (and back to dev for new cycles in some commits).
      • Update @fjell/registry and other Fjell dependencies to current patch versions.
      • Normalize formatting (whitespace, trailing newlines) to make diffs and future merges cleaner.
    • A direct change in package.json shows @fjell/registry moved from ^4.4.32 -> ^4.4.33 and the top-level package version set to 4.4.28.

Breaking Changes and Compatibility Notes

  • ESM packaging and module entry points

    • Switching to module + exports and changing compiler targets to ES2022 means consumers relying on legacy CommonJS require() entry points may need to adjust bundler or runtime configuration. Projects that explicitly import the package via CommonJS may need to ensure their tooling supports packages that publish ESM output with proper exports mapping.
  • Test behavior and CI

    • Vitest configuration simplifications and changes to polyfills could alter test timings, coverage outputs, or environment assumptions. If CI relies on very specific coverage filters or explicit timeouts, verify the new defaults.

Upgrade and Migration Notes

  • For consumers upgrading to 4.4.28:
    • No API-level functional changes are recorded in these commits, but confirm your runtime and bundler support ESM-style packages and Node toolchain handles ES2022 outputs.
    • If tests or CI previously depended on the older Vitest config or global logging mocks, update test setup to use the new polyfills and mocking approach.
    • Ensure package-lock.json is refreshed (npm install or equivalent) after upgrading to pick up the bumped @fjell/registry tarball and integrity values.

Files and components touched (representative)

  • package.json — version -> 4.4.28, dependency bumps, ESM fields
  • package-lock.json — updated @fjell/registry entry and normalized lock entries
  • tsconfig.json — emit settings changed (sourceMap, declaration, outDir), target/module set to ES2022
  • vitest.config.ts — simplified configuration, enabled globals
  • tests/setup.ts — Node polyfills for fetch/FormData/Blob/File, remove global logging mock
  • docs/package.json — replaced npx copy-docs with pinned node script path

If you maintain downstream projects that import this package, verify ESM compatibility and run your test suite against 4.4.28. If any of your CI scripts rely on previous explicit Vitest coverage filters or timeouts, update them to match the simplified configuration or reintroduce the specific settings in your CI config.

If any specific runtime issue is encountered after upgrading (module resolution, test failures), regenerate your lockfile and confirm the consuming environment supports ES module resolution for packages that publish module/exports fields.