Summary
Priority 4 currently favors modernizing the existing backend Mongo test stack in place rather than immediately replacing it. That is the lower-risk near-term move, but we should still make an explicit determination about whether the repo ought to shift from mongodb-memory-server to an actual local MongoDB replica set for backend tests.
Current repo practice
The current backend Jest path still depends on the @shelf/jest-mongodb + mongodb-memory-server stack:
jest.backend.config.ts composes the @shelf/jest-mongodb preset
jest-mongodb-config.js pins MongoDB to 6.0.14
.github/workflows/netlify-api-test.yml and scripts/ci-local.sh export MONGOMS_DOWNLOAD_URL to work around platform/archive resolution problems
- backend tests consume preset-provided globals such as
__MONGO_URI__ and __MONGO_DB_NAME__
This is workable, but it is also the source of the repo's current Mongo test fragility.
Why this is still worth investigating
MongoDB's own documentation points toward replica-set-backed development/testing when production-like behavior matters:
That is not the same as saying the repo must switch immediately. It does mean we should decide intentionally whether our long-term backend test model should remain a modernized mongodb-memory-server path or move to an actual local replica set.
Important nuance
This is not a claim that mongodb-memory-server is obsolete. Current upstream docs say it supports modern MongoDB versions, supports replica sets, and works on current Node lines:
So the near-term Priority 4 direction can still be: modernize the existing Mongo test stack first.
Requested outcome
Please investigate and make a determination on this question:
- Should this repo continue with a modernized
mongodb-memory-server-based backend test stack?
- Or should it shift to an actual local MongoDB replica set for backend tests?
Expected follow-up
A later plan/checklist should:
- compare the two approaches for this repo specifically
- evaluate contributor ergonomics, CI/local parity, determinism, and maintenance cost
- make an explicit recommendation
- if a shift is preferred, define the migration plan and documentation updates
Related planning artifact: docs/plans/Priority4MongoReplicaSetTestingMiniPlan.md
Summary
Priority 4 currently favors modernizing the existing backend Mongo test stack in place rather than immediately replacing it. That is the lower-risk near-term move, but we should still make an explicit determination about whether the repo ought to shift from
mongodb-memory-serverto an actual local MongoDB replica set for backend tests.Current repo practice
The current backend Jest path still depends on the
@shelf/jest-mongodb+mongodb-memory-serverstack:jest.backend.config.tscomposes the@shelf/jest-mongodbpresetjest-mongodb-config.jspins MongoDB to6.0.14.github/workflows/netlify-api-test.ymlandscripts/ci-local.shexportMONGOMS_DOWNLOAD_URLto work around platform/archive resolution problems__MONGO_URI__and__MONGO_DB_NAME__This is workable, but it is also the source of the repo's current Mongo test fragility.
Why this is still worth investigating
MongoDB's own documentation points toward replica-set-backed development/testing when production-like behavior matters:
That is not the same as saying the repo must switch immediately. It does mean we should decide intentionally whether our long-term backend test model should remain a modernized
mongodb-memory-serverpath or move to an actual local replica set.Important nuance
This is not a claim that
mongodb-memory-serveris obsolete. Current upstream docs say it supports modern MongoDB versions, supports replica sets, and works on current Node lines:8.2.1: https://typegoose.github.io/mongodb-memory-server/docs/api/config-options/So the near-term Priority 4 direction can still be: modernize the existing Mongo test stack first.
Requested outcome
Please investigate and make a determination on this question:
mongodb-memory-server-based backend test stack?Expected follow-up
A later plan/checklist should:
Related planning artifact:
docs/plans/Priority4MongoReplicaSetTestingMiniPlan.md