Skip to content

Switch to local key guards, tighten public exports, bump peer packages, and package.json version removal

Choose a tag to compare

released this 20 Dec 12:38
· 14 commits to working since this release

Overview

This release performs three coordinated changes: (1) it centralizes runtime key/type guard logic inside the repository and tightens the package export surface, (2) it updates / pins a few @fjell peer package versions, and (3) it removes the explicit version field from package.json. Together these edits are aimed at clarifying runtime responsibilities (use local KUtils for guards), reducing accidental re-exports of the external types barrel, and aligning dependency versions — but they also change the package metadata and public API surface in ways that may require action from downstream consumers and CI/publish tooling.

Breaking changes

  • package.json no longer contains a version field (commit 3cf9ea1)
    • What changed: The explicit "version" entries were removed from package.json in this diff (the commit message documents deletion of the version keys). There is no replacement or new version field added in the same commit.
    • Why it matters: Many tools (npm / yarn publish, some CI checks, changelog generators, release scripts, and any local workflows that read package.json.version) expect a version value. With the field removed those tools will either fail or need an alternate source for version metadata.
    • What to do: Restore a version field or update tooling to read version metadata from another source (for example a release pipeline artifact or an external package manifest). If you run automated releases or publish directly from this package, add the version entry back or ensure CI injects it before publishing.

Public API / exports and runtime guard behavior

  • Route runtime key guard functions to local KUtils and tighten barrel exports (commit 333abc4)
    • What changed (from the commit message and diffs):
      • Files that previously imported runtime guards or types from local sources or from the package barrel were changed to import types and runtime utilities differently:
        • src/Coordinate.ts now imports Coordinate and ItemTypeArray from @fjell/types (explicit type/value import) and removes internal key type re-exports.
        • Multiple modules (src/event/matching.ts, src/item/IQUtils.ts, src/item/IUtils.ts and others shown in the diff) switch to using the repository's key utilities (../key/KUtils or './key/KUtils') for runtime guards (isComKey, isPriKey) rather than assuming those guards are exported from the @fjell/types barrel.
      • src/index.ts was adjusted to reduce the amount of re-exported symbols. The commit trims broad re-exports of types/guards and now explicitly exports a narrower set of items (for example, createCoordinate is exported from ./Coordinate, IFactory/IQFactory and a curated set of KUtils utilities are re-exported). The commit message reads: "stop exporting all symbols from '@fjell/types' and remove the direct Coordinate export, leaving only createCoordinate from ./Coordinate."
    • Why it matters: This is an intentional change in where runtime logic lives and what the package publicly exposes:
      • Runtime guards: code inside the package now relies on the local implementation in key/KUtils for runtime checks. That makes behavior more explicit and avoids depending on a types package to provide runtime guard functions.
      • Public surface: consumers that relied on indirectly re-exported symbols from the core package (for example, expecting to import certain runtime helpers or type-helpers from @fjell/core's barrel) may no longer find those symbols where they were previously available.
    • Impact and migration guidance:
      • Internal contributors: If you maintain other modules in this repo, be aware that imports for runtime guards should now come from key/KUtils (local path) as shown in the updated files. The change consolidates runtime checks into a single place (KUtils).
      • External consumers: If your code imported runtime helpers or types from @fjell/core's barrel and relied on re-exporting behavior (for example: import { isPriKey } from '@fjell/core'), update imports to point directly to the source package that provides those items (for types in @fjell/types) or to the new explicit exports documented in src/index.ts. The commit intentionally narrows the barrel; check your imports against the new exported names (createCoordinate remains exported from ./Coordinate; other items may have been removed from the top-level barrel).
      • Tests: Some tests were adjusted to match the new guard semantics (see tests changes). If you have test suites that assume the previous behavior, update them to reflect the new import paths and type/guard behavior.

Improvements and fixes

  • Centralize and clarify type vs runtime dependencies (commit 333abc4)

    • What changed: Several files updated their imports to more clearly separate compile-time types (imported from @fjell/types) from runtime guards and utilities (imported from local key/KUtils). Examples include AItemService, Coordinate, event emitter/event files, IQFactory, IUtils, KUtils, and many wrapper modules under src/operations/wrappers (diff shows many files switching their imports to '@fjell/types' for types and '@fjell/validation' or local KUtils for runtime functions).
    • Why it matters: The change clarifies responsibilities: the types package provides type-level definitions and shape information, while runtime checks and guards — which must operate on arbitrary inputs at runtime — are implemented and maintained locally where their behavior and logging can be controlled. That reduces accidental coupling and makes maintenance of runtime checks explicit.
    • Related small fixes: the commit removed an accidental duplicate semicolon in IQUtils dateTimeReviver and performed other small style adjustments noted in the diff.
  • Tests updated to align with guard behavior and matching changes (commit 333abc4)

    • What changed: A small test expectation in tests/event/matching.test.ts was updated (the test now uses an explicit non-empty loc array in the comKey case). Several other test files were edited (diff shows many tests changed or deleted). The commit message notes test adjustments that mirror the changed matching/import behavior.
    • Why it matters: Tests were updated to reflect the new guard semantics (notably, how empty loc arrays are treated and how isComKey/isPriKey behave). If you run test suites locally or in CI, ensure your test dependencies are aligned and import paths updated where the library surface changed.

Dependency updates

  • Bumped peer/dependency versions in package.json (commit fcc0158)
    • What changed: package.json dependency entries updated:
      • "@fjell/logging": ^4.4.65 → ^4.4.66
      • "@fjell/types": 4.4.4 → 4.4.5
      • "@fjell/validation": 4.4.1 → 4.4.2
    • Why it matters: These are upstream patches/minor releases likely containing bug fixes or small improvements. Consumers should run a fresh install and update lockfiles/CI caches so the new versions are picked up. No code changes accompany these bumps; they are dependency alignments. See commit fcc0158 for details.

Repository / build script adjustments

  • Trimmed validation build artifacts in build script and adjusted packaging metadata (diff evidence; commit 333abc4...)
    • What changed (observed in build.js and package.json diffs): The build script no longer builds a separate validation module (lines that built src/validation/index.ts were removed). package.json package exports removed the "./validation" subpath and removed references to dist/validation TypeScript declarations. package.json also has new dependency entries for @fjell/types and @fjell/validation (see Dependency updates above).
    • Why it matters: The repository no longer publishes a separate ./validation entry point from the same package build (the package exports changed to remove the validation subpath). Consumers that previously imported from '@fjell/core/validation' may need to switch to the dedicated package '@fjell/validation' (note the package.json now depends on that package). This aligns with moving validation responsibilities to a dedicated package instead of shipping a built submodule inside core.
    • Migration guidance: If your code previously used '@fjell/core/validation' (or './validation' re-export from core), update imports to '@fjell/validation' where the validation functions now live. The diff shows many internal files switched validation imports to '@fjell/validation'. External consumers should mirror that change.

What patterns and intent are visible across these changes

  • Consolidation of runtime responsibilities: The changes repeatedly move runtime guard functions to a single local implementation (key/KUtils) and make imports explicit. This reduces ambiguity about where runtime checks live and allows maintainers to change guard behavior without depending on a types-only package to provide runtime code.

  • Narrowing of the public barrel: src/index.ts was intentionally pruned to avoid broad re-exporting of external package symbols. The pattern shows a preference for explicit exports and for consumers to import from the package that owns a particular capability rather than relying on transitive or accidental re-exports.

  • Splitting validation into a dedicated package: The build script deletion of the separate validation build and package.json export removal, plus internal imports that use '@fjell/validation', indicate a move toward treating validation as an external, separately versioned package rather than as an internal submodule of core.

  • Safety-first changes to tests and runtime checks: Tests and utilities were updated to reflect the new guard decisions (how empty loc arrays are interpreted and where isComKey/isPriKey live). The changes indicate care to maintain correct runtime behavior while simplifying package boundaries.

Concrete actions for consumers and contributors

  • If you consume this package in code or in CI workflows:

    • Check package.json usage: the explicit version field is removed. If your tooling reads package.json.version, restore the version or adjust tooling to obtain version metadata elsewhere. (commit 3cf9ea1...)
    • Update imports for validation: switch imports from the internal './validation' re-export to the dedicated '@fjell/validation' package where validation functions now live (diff and build/package.json edits demonstrate this). Run a fresh install to pick up the bumped versions (commit fcc0158...).
    • Update imports for runtime guards / utilities: if your code relied on transitive re-exports from '@fjell/core' for runtime guard functions (e.g., isComKey/isPriKey), change imports to reference their definitive location — either the new exported names from core's curated barrel or the dedicated packages that own them. The diff shows internal modules now import guards from './key/KUtils' and types from '@fjell/types' (commit 333abc4...).
  • If you publish or run automated tools against this repo:

    • Ensure your publish pipeline (npm publish, changelog generator, release scripts) can handle package.json with no version field, or ensure CI injects a version before publish. Removing the version will break processes that read it directly (commit 3cf9ea1...).

References (commits in this release)

  • Remove version entries from package.json — commit 3cf9ea1
  • Bump @fjell/logging, @fjell/types, @fjell/validation versions in package.json — commit fcc0158
  • Clean up and relocate key/type imports; fix minor code/style issues; trim re-exports — commit 333abc4

Notes and caveats

  • All statements above are constrained to the changes documented in the commit messages and visible diffs for this release. The diff indicates numerous files were edited to use '@fjell/types' for compile-time types and local implementations or '@fjell/validation' for runtime validation. The most user-visible effects are the change in package metadata (version removal), the dependency bumps, and the altered export/import surfaces that can require consumer-side import path updates.

If there are specific integrations you maintain (publishing pipelines, packages that import runtime helpers from this package, or CI scripts reading package.json.version), list them and I will give exact lines to change or a small migration patch to apply.