Fix Plan — mongoose-unique-validator (tag v5.0.1)

Goal: Create a minimal, self-contained fork starting exactly from tag v5.0.1 of mongoose-unique-validator, implement a bug fix for private/internal use, and validate via tests. Do not include npm publish steps here.

1) Context & Constraints

• Upstream repo: https://github.com/mongoose-unique-validator/mongoose-unique-validator
• Target snapshot: Git tag v5.0.1 (frozen state; no upstream updates expected).
• Outcome: A new repo owned by us, with a branch containing the fix and a green test suite.
• Out of scope: npm publish / package rename instructions (handled separately later).

3) Bootstrap (start from the tag, not the default branch)

1. Shallow clone the tag:

   git clone --branch tags/5.0.1 --single-branch https://github.com/mongoose-unique-validator/mongoose-unique-validator.git muc-fix
   cd muc-fix

2. Initialize a clean repository under our account (optional if we’ll just push to a new empty repo):

   git remote remove origin
   git remote add origin <https://github.com/<org-or-user>/<new-repo>.git>
   git checkout -b fix/v5.0.1-my-bug

Rationale: cloning the exact tag guarantees we don’t accidentally include later upstream changes and keeps the history minimal.

4) Inspect project metadata to locate the code & tests

• Open package.json and note:

  • main entry (primary module file to patch).
  • scripts (how to run tests/lint).
  • Any engines, dependencies, peerDependencies.

• Identify the unit/integration tests folder (commonly test/ or similar). We’ll add a regression test here.

If the tests require a MongoDB URI, export MONGODB_URI=mongodb://localhost:27017/muc_test (or whatever variable the tests read). Otherwise, adapt the test setup to point at local Mongo.

5) Install & run the existing test suite

npm ci || npm install
npm test

• If tests depend on a running MongoDB instance, ensure the Docker container is up (see §2) and re-run.
• Fix any environment variable requirements (check test setup files for clues like process.env.MONGODB_URI).

Success criteria: Existing suite passes (or at least is reproducible locally) before introducing changes.

6) Reproduce the bug (add a failing test first)

1. Create a new test file under the existing test directory structure. Suggested naming:

   • test/regression/<short-bug-key>.spec.js (or .ts, follow repo conventions).

2. Write the minimal scenario that triggers the bug against mongoose + this plugin. Keep it small and deterministic.

3. Run:

   npm test -- --grep <short-bug-key>

   Ensure it fails for the right reason.

Tip: Use the library’s public API exactly as users would. Avoid testing internals unless necessary.

7) Implement the fix

1. Open the module’s entry file referenced by package.json → main (e.g., index.js/lib/index.js).
2. Apply the minimal code change that resolves the failing test.
3. Keep coding style consistent with the project (check .editorconfig, ESLint/Prettier config if present).

Guardrails

• Do not introduce breaking changes to the plugin’s public API.
• Avoid bumping dependency majors unless strictly required to fix the bug.
• If logic is complex, add inline comments explaining the edge case you’re handling.

8)