serve.zone/dcrouter
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases 103 Wiki Activity

103 Releases 579 Tags

RSS Feed
  • v32.1.1 c80b6f130b
    Compare

    DcRouter v32.1.1
    Release / build-and-release (push) Successful in 17m36s
    Details
    Stable

    jkunz released this 2026-09-19 03:54:43 +00:00 | 79 commits to main since this release

    2026-09-19 - 32.1.1

    Changes

    • move document persistence from @push.rocks/smartdata to @lossless.org/client/nosqldb (db) This is a patch: no public API, no persisted byte and no operator-facing behaviour changes.
      • @push.rocks/smartdata is superseded; @lossless.org/client's ./nosqldb entry is the same ORM under new ownership (nosqldbLineage records the upstream baseline, @push.rocks/smartdata 11.14.2, which is byte-identical to the 11.14.1 dcrouter 32.1.0 shipped apart from the added NoSqlConnection, the lineage constant and a change-stream capability guard, plus upstream 11.14.2's publishModelIndexes change, which stops excluding unique single-field indexes from the in-memory regularIndexes reconciliation listing — index creation and every persisted index option are produced by byte-identical code). The dependency moves, the ORM does not.
      • ts/plugins.ts imports the ORM from @lossless.org/client/nosqldb and keeps re-exporting it as plugins.smartdata, because that is the name all ~670 call sites use and the exported surface is unchanged; renaming it would be churn without a behavioural difference.
      • No persisted byte moves. Collection names, _id generation, _createdAt/_updatedAt, the _smartdataRevision exact-persistence fence and every index name and option are produced by the same code as before. test/test.nosqldb-persisted-bytes.node.ts writes one document per persistence family (ordinary, exact, defineCollectionModel, cached document, EasyStore), reads the stored BSON back through Model.inspectStoredDocuments and asserts the literal shape 32.1.0 created, including the index names of all five collections.
      • @push.rocks/smartmigration moves to 2.0.1, which takes the ledger database as the client's SmartdataDb and peers on @lossless.org/client. The ledger document is unchanged: same SmartdataEasyStore collection, same _id smartmigration-ledger, same nameId smartmigration:smartmigration (asserted by test/test.migrations.node.ts and test/test.smartdb-upgrade-compatibility.node.ts).
      • @idp.global/sdk is pinned to 18.0.0, whose ./server account store is built on the same @lossless.org/client/nosqldb and declares a hard peer on @lossless.org/client. The 17.x server entry decorated its account document with its own @push.rocks/smartdata copy, so the db handed to SmartdataAccountStore no longer matched its parameter type (compile error) and the document never resolved a database at runtime. With 18.0.0 the sdk and dcrouter share one physical client install, so the ORM identity is the same object on both sides. Public names (SmartdataAccountStore, setAccountDocSmartdataDb, the smartdataDb option) and the stored account bytes (collection IdpSdkAccountDoc, indexes _id_ and unique id_1, scrypt:v1 password hashes) are unchanged, so existing admin accounts keep working untouched.
      • The test database starters (@push.rocks/smartdb 5.7.1, and the 2.14.6 / 5.2.2 engines replayed by the rollback and upgrade-compatibility fixtures) are unaffected: they hand over a connection URI, and the client connects over the same wire protocol.
      • mongodb and bson each resolve to a single version, so instanceof ObjectId inside exact persistence keeps holding across package boundaries.
    Downloads