Store Chronicle read models in the collection Arc reads them from

[woksin]

When an app uses Arc's MongoDB integration together with its Chronicle integration, Chronicle now stores each projected read model in the collection Arc reads it from.

Before, Chronicle's TypeScript client named the container after the read model identifier (User), while Arc's MongoDB naming policy read a pluralized collection (Users). Apps needed the collectionName: type => type.name workaround.

Changes

• One naming rule: resolveMongoCollectionName(options, type) in @cratis/arc.mongodb is now the only place that computes collectionName?.(type) ?? namingPolicy.collectionName(type). withMongoDB uses it for its collection tokens and registers it as a service under a new readModelCollectionNameResolver token in @cratis/arc.core. That avoids a dependency from arc.chronicle on arc.mongodb.
• Wiring: withChronicle looks the rule up lazily when the runtime is built, so the order in which the two integrations are registered doesn't matter. The Chronicle client Arc creates gets readModelNamingPolicy = (identifier, type) => rule(type) ?? identifier, using @cratis/chronicle 6.29.0's new option.
  • Only classes in withMongoDB's readModels, which are the ones Arc reads, are renamed. Anything else keeps its identifier.
• Override: ChronicleRegistration.readModelNamingPolicy overrides the rule. If you pass your own client, Arc leaves it alone. Passing a policy together with your own client throws, because Arc can't apply it; the docs show the one-liner to set it yourself.
• Without withMongoDB: no policy is passed, so the identifier is used as before.
• Dependency: @cratis/chronicle goes to 6.29.0, and its peer floor rises to ^6.29.0.
• Docs: the camel-casing snippet drops the workaround. mongodb/naming-policies.md, chronicle/registration-options.md and chronicle/read-models/index.md describe the behaviour.

Upgrade notes (for the release notes)

• @cratis/chronicle must be 6.29.0 or later.
• Default naming policy: if an app uses withMongoDB + withChronicle with the default policy, Chronicle now writes read models to the pluralized collection Arc was already reading. That collection is populated once the projection is replayed. The previous, unread collection is left as it is.
• The workaround: apps using collectionName: type => type.name get identical names.
• Invalid overrides: a throwing or empty collectionName override now fails when the Chronicle client registers its read models.

Specs

• The resolver and the withMongoDB rule, including classes outside readModels.
• The Arc-created client's policy for a class, for an identifier only, with an explicit override, and with no MongoDB.
• An own client left untouched, and rejected when combined with a policy.
• A cross-package spec that runs the real withMongoDB + withChronicle in both orders.

Checked locally, split into CI's yarn ci steps:

• install, build, proxies, the declaration/consumer/peer-floor/fetch/node checks, lint and typecheck
• yarn test (2896 tests)
• the decorator suites and docs:lint
• docs:examples and docs:snippets, each with its self-test
• the release script tests and set-version --check

Not run locally: the Library Docker e2e (the local kernel container's MongoDB refused connections), tutorial-e2e and drizzle-integration. CI runs them.

Review: same-provider (Anthropic-only). No defects were found; the minor findings are addressed. It's labelled minor: packages are 0.x and the Chronicle integration is experimental, and the peer floor and the collection change are called out above.

Refs Cratis/Documentation#19, Cratis/Chronicle.TypeScript#149