Dependency bumps, added runtime deps, and placeholder tsconfig; package.json version entries removed

Overview

This release is focused on dependency management and a small repo housekeeping change. The changes are limited to package.json and the addition of a minimal tsconfig.build.json. Collectively they alter the resolved runtime dependency graph (additional packages and patch bumps) and remove explicit version metadata from package.json; a new, currently-empty build tsconfig was also added. Read the sections below for the practical implications and what to check after upgrading.

Breaking Changes

• Removed the package.json "version" fields (commit 941d86c)
  • What changed: Two version lines that were present in package.json were deleted (commit 941d86c). The manifest no longer contains those explicit "version" entries.
  • Why it matters: Some tools and workflows read package.json for the package version (for example, lightweight scripts, publish tooling that inspects package.json without using npm metadata, or custom CI checks). With the version entries removed, those tools may not find an expected package version and could behave differently or fail.
  • What to do: Ensure your publish and CI pipelines do not rely on an in-repo package.json version string. Rely on the registry/packaging tool (npm/yarn) or re-add a version field if your tooling requires it. This change appears intentional in the commit message (941d86c) and is limited to the manifest file.

New and Updated Runtime Dependencies

• Bumped several @fjell packages and added new runtime dependencies (commit 7b9c0bd)
  • What changed: package.json dependency versions were updated:
    • "@fjell/core" ^4.4.74 → ^4.4.76
    • "@fjell/http-api" ^4.4.64 → ^4.4.66
    • "@fjell/types" ^4.4.5 → ^4.4.6
    • "@fjell/validation" ^4.4.2 → ^4.4.3
  • New runtime dependencies were added to package.json (note: these are in dependencies, not devDependencies):
    • "@fjell/logging" ^4.4.66
    • "@fjell/registry" ^4.4.82 (later further bumped to ^4.4.83; see next section)
    • "deepmerge" ^4.3.1
  • Why it matters: These are patch-level upgrades for existing @fjell packages and three new runtime packages. Patch bumps generally indicate backward-compatible fixes, but they change the resolved dependency graph and can affect runtime behavior indirectly (e.g., bug fixes that alter side effects, additional transitive dependencies, or new code paths).
  • What to do: After pulling this release, regenerate the lockfile or run a clean install in CI to ensure deterministic resolution (commit 7b9c0bd notes that lockfile regeneration is required). Run test suites or smoke tests that exercise runtime paths interacting with logging, registry, and deepmerge to confirm no behavioral changes appear in your environment.

Patch follow-up: @fjell/registry bumped to ^4.4.83 (commit 3d24fa8)

• What changed: After the prior updates, the runtime dependency for "@fjell/registry" was bumped again from ^4.4.82 to ^4.4.83 (commit 3d24fa8).
• Why it matters: The commit message explicitly states this is a patch-level bump intended to be backward-compatible but emphasizes that lockfile regeneration and CI images should be updated to pick up the new resolution (3d24fa8). Because this changes the resolved dependency graph, installations done before regenerating the lockfile may resolve a different transitive set than installations done after.
• What to do: Regenerate your lockfile (npm/yarn) and rebuild CI images. If you pin dependencies in deployment artifacts or container images, update those artifacts to use the regenerated lockfile so the ^4.4.83 resolution is picked up consistently.

Build configuration changes

• Added a placeholder tsconfig.build.json that contains an empty JSON object (commit 941d86c)
  • What changed: A new file tsconfig.build.json was added at the repo root. The file contains a minimal/empty JSON object ({}); it does not extend the base tsconfig or define compilerOptions, include, or exclude sections.
  • Why it matters: Adding a tsconfig.build.json indicates intent to introduce a build-specific TypeScript configuration, but since the file is empty it is currently inert. Tooling that looks for tsconfig.build.json will find the file but will not get any build-specific settings from it until it is populated.
  • What to do: If your build tooling expects specific compilerOptions in tsconfig.build.json, populate this file or point the build to the existing tsconfig.json. Otherwise, the new file should be harmless but could be confusing to maintainers until it is populated with real options.

Patterns, motivations, and implications

• Pattern: repository-level dependency hygiene and progressive runtime stabilization

  • The commits show a deliberate sequence: add/upgrade runtime dependencies and then follow up with a targeted patch bump to registry (commits 7b9c0bd → 3d24fa8). This indicates active maintenance of the runtime dependency surface and a conservative approach (patch bumps only) to avoid API changes while still moving forward on fixes.

• Pattern: repository housekeeping with an unfinished build config

  • The tsconfig.build.json addition (commit 941d86c) appears to be the start of a move toward a separate build-time TypeScript configuration, but the placeholder content suggests the work is incomplete or staged across multiple commits. Expect a future commit to populate that file or the project to rely on the root tsconfig until that happens.

• Practical implications for CI and install reproducibility

  • Multiple commits explicitly call out the need to regenerate lockfiles and update CI images (commits 7b9c0bd, 3d24fa8). Because dependency resolution changed (added deps and patch bumps), reproduceability requires updating the lockfile and any build artifacts that embed node_modules. Plan to regenerate and commit the lockfile or rebuild CI/container images that depend on precise installs.

Developer notes / checklist

• For maintainers and CI operators:

  • Regenerate the lockfile (npm install / npm ci / yarn install) and commit it, or update your image build process to use the new resolution (commits 7b9c0bd, 3d24fa8).
  • Confirm that no tooling in your pipeline relies on a package.json version field (commit 941d86c). If such tooling exists, update it to read version from the registry or reintroduce a version field intentionally.
  • Decide whether tsconfig.build.json should be populated now or left as an intentional empty placeholder (commit 941d86c). If builds fail because a build-specific tsconfig was expected, either remove the file or add the necessary compilerOptions.

• For downstream consumers/installers:

  • Run full test and smoke-test suites after updating dependencies; patch bumps are meant to be safe but can alter runtime behavior in edge cases (commits 7b9c0bd, 3d24fa8).
  • Watch for any increases in installation footprint due to the new runtime dependencies (@fjell/logging, @fjell/registry, deepmerge) since these are installed for consumers now (commit 7b9c0bd).

References (commits mentioned in these notes)

• Remove package version entries and add placeholder tsconfig.build.json: commit 941d86c
• Bump several @fjell packages and add runtime deps: commit 7b9c0bd
• Bump @fjell/registry runtime dependency to patch release: commit 3d24fa8

If anything in your environment depends on package.json version fields, on a specific dependency graph, or on a populated tsconfig.build.json, take the actions listed above before upgrading. The changes are intentionally minimal in scope (no source code modifications were made), but they affect build and install-time behavior and thus require coordination with CI and publishing workflows.