Bump @adaptivestone/framework from 5.3.2 to 5.3.3

[dependabot]

Bumps @adaptivestone/framework from 5.3.2 to 5.3.3.

Changelog

Sourced from @​adaptivestone/framework's changelog.

Changelog

All notable changes to this project will be documented in this file.

The format is based on Keep a Changelog, and this project adheres to Semantic Versioning.

[Unreleased]

Fixed

• configureTestServer now works in the documented arrangement — the boot no longer beats the preload that declares the options. node:test runs a root before() registered from a --import preload immediately, synchronously inside the before() call — while the preload's module graph is still evaluating. The shipped setup glue therefore booted the test server, and closed the options window, during its own import; the preload's module body — where the 5.3.3 snippet places the configureTestServer call, below its hoisted imports — ran only afterwards, so every test file died on the helper's own "must be called before the test server boots" guard. The glue's before() hook now yields one microtask before booting, resuming after the whole preload graph has evaluated, so the documented snippet (setup-glue import above, call at module scope below) works as written. One arrangement remains out of reach: a preload that awaits at top level before calling — deferral cannot outwait arbitrary async work — and the guard's error message now names the fix for it (move the call into a separate module imported before the setup glue). Pinned by a spawned-runner regression test that executes the documented preload arrangement under --test.

Added

• The shipped test bootstrap now accepts project Server options, so bootHttp runs under test. Server takes exactly two things — folders and the bootHttp hook — and the test bootstrap passed only the first, hardcoding new Server({ folders }). Every project that wires app-wide HTTP behavior in bootHttp (error handlers via registerErrorHandler, ad-hoc routes, Express middleware) therefore ran its tests against a server that had none of it: a mapped 400 in production showed up as a 500 under test, with nothing reporting the difference. Declare them with configureTestServer from tests/testHelpers.js, at module scope in the preload that imports the setup glue:

  import { configureTestServer } from '@adaptivestone/framework/tests/testHelpers.js';
  import '@adaptivestone/framework/tests/setupNodeTest.js';
  configureTestServer({ bootHttp: (app) => { /* same wiring as production */ } });

  folders stays owned by the bootstrap (it resolves those from the TEST_FOLDER_* env vars). Calling it after the server has booted throws rather than silently doing nothing — a late call cannot retroactively wire the running server, and a silent skip is exactly the failure this fixes. Also closes a coverage hole: bootHttp shipped in 5.1 with no test exercising it end to end, for the same reason.

Fixed

• Plain nested paths carried a phantom _id on hydrated documents. Mongoose builds a subdocument, and generates an _id for it, only for the { type: { … } } spelling; a plain nested object (name: { first: String, last: String }) is a path grouping that never gets an _id at runtime. InferHydratedDocType types both the same way, intersecting { _id: ObjectId } onto nested paths too — so doc.name._id compiled for a value that is always undefined, and assigning the real runtime shape (doc.name = { first: 'Ada' }) was a type error on a property Mongoose will never persist, pushing consumers to Omit<…, 'name'> bridges or unknown casts at every nested-path call site. The framework's hydrated correction — which already strips the _id Mongoose adds to _id: false subdocuments — now also drops it from plain nested paths, at any depth, using the same no-type-wrapper discriminator the override pass uses. Real single-nested subdocuments keep their _id, and the raw/lean/create surfaces are untouched: those already matched runtime exactly. The framework's own User.name was affected.

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)