packages/mongo-adapter/src/index.ts:3

• [nitpick] The createDocumentMatcherFromFilter function appears to be an internal helper. Exposing it in the public index may lead users to rely on an unstable API surface. Consider keeping it private or clearly marking it as experimental in documentation.

export { createPredicateFromFilter, createDocumentMatcherFromFilter } from './filter';

packages/mongo-adapter/src/updateFilter.ts:494

• This is a major entry point for users applying update filters. Adding JSDoc comment describing expected inputs, optional parameters, and error cases would help users integrate it correctly.

export const createTransformFromUpdateFilter = <T extends { _id: string }>(modifier: UpdateFilter<T>) => {

packages/mongo-adapter/src/lookups.ts:4

• The dontIterate flag in buildResult governs whether arrays are expanded. There are no tests covering the behavior when dontIterate is true. Consider adding tests to validate that branches with dontIterate skip nested array expansion.

const buildResult = (arrayIndices: ArrayIndices | undefined, dontIterate: boolean, value: unknown): [LookupBranch] => {

packages/mongo-adapter/src/filter.ts:483

• Using the Function constructor to compile $where string expressions can introduce code‐injection risks if untrusted input reaches this logic. Ensure inputs are sanitized or consider deprecating string-based $where support.

		selectorValue = Function('obj', `return ${selectorValue}`) as (this: T, doc: T) => boolean;

packages/mongo-adapter/src/updateFilter.ts:1

• [nitpick] This file is over 600 lines and implements all update operators inline. Consider splitting each operator or the findModTarget logic into separate modules to improve readability and ease future maintenance.

import type { Document, Filter, FilterOperators, Sort, UpdateFilter } from 'mongodb';