SimpleSchema validates a MongoDB update document as well as an object

Validating the update, not just the object

SimpleSchema validates JavaScript objects to ensure they match a schema. The distinctive part is what else it can validate. The object you validate can be a MongoDB update document, also known as a modifier object, and the package understands how to properly validate it such that the object in the database, after undergoing modification, will be valid.

That is a genuinely different problem from validating a document. When you validate a plain object you check the fields that are present. When you validate an update document you have to reason about what the update will do: a $set that sets a field to the wrong type, a $unset that removes a required field, a $push that appends an item which does not match the schema of the array it goes into. A validator that only understands plain objects will pass those.

The cleaning feature covers the same ground. Object cleaning can fix potential validation errors automatically, avoiding unnecessary errors for your users, and cleaning also supports MongoDB update documents.

This is the reason to pick this package over the others, and the documentation is upfront that the other validators named in it, simplecheck, joi and yup, do not do this.

Cleaning, and why it exists

The cleaning behaviour is the second feature worth understanding, and it is what makes the package usable in front of end users rather than only in a test suite.

Cleaning converts types, removes unsupported properties, and adds automatic values, so that the object is then more likely to pass validation. The reasoning is on the documentation: because it can fix potential validation errors automatically, it avoids unnecessary errors for your users.

That is a design decision with a consequence. A strict validator tells a user their date string is wrong. A cleaning validator might coerce it, strip an unknown field, or fill in a default and then pass. For a form submission where the user typed a date in the wrong format, that is friendlier. For an internal API boundary where a malformed payload should be rejected loudly, it can hide a bug in the caller.

So whether you use clean or not is a decision about who absorbs the error, and the package supports both, since there is an explicitly clean method as well as validation with automatic cleaning, and there is a whole section on cleaning objects in the table of contents.

The type conversion is the part that needs care in JavaScript specifically, where a number arriving as a string from a form is common but where silently coercing it can also mask a backend contract violation.

Error messages you can show to a user

The error handling is the third feature the documentation puts forward, and it is a real differentiator for anyone shipping a form.

The package has a customizable error message system with decent English language defaults and support for localization, which the documentation says makes it easy to drop the package in and display the validation error messages to end users. The table of contents has a whole section on customizing validation messages, and the lingo concept appears near the top of the contents, which is the term for the message catalogue.

The mechanics support this. There are ways to perform validation, with named validation contexts and unnamed ones, so you can validate a user-facing form against one set of rules and a data import against another. There is a way to get the errors rather than throw, a way to get a list of invalid keys with their validation error messages, and a way to customize the error that is thrown.

There is also a debug mode, which is the sort of thing that matters when you are working out why a document is failing validation in production. The scope of customization is unusual for a validator, and the documentation makes clear it goes down to per-field messages.

Schemas are objects, and they compose

The schema definition itself is a plain object, which is what makes the package usable in a codebase with shared definitions.

There are shorthand definitions and longhand definitions, and they can be mixed. The shorthand covers the common cases, while the longhand gives every property an explicit key, with the table of contents listing type, label, optional, required, min and max, exclusiveMin and exclusiveMax, minCount and maxCount, allowedValues, regEx, skipRegExCheckForEmptyStrings, blackbox, trim, custom, defaultValue and autoValue, plus function properties and the method for getting field properties.

The composition features are the part that pays off in a real application. You can define multiple definitions for one key, and you can extend schemas, with a documented section on overriding when extending, and there are subschemas for nested structures. You can also extract a schema, which is how you reuse a validated sub-object without duplicating its rules, and there is a raw definition escape hatch for cases the options do not cover.

A separate feature is converting a SimpleSchema to a JSON Schema, which is useful when you need to publish a schema for a client or a tool that only speaks JSON Schema. There are also add-on packages listed for extending the core.

Ten years old, and honest about what that costs

The project states its own strengths and its own weaknesses, which is unusual and useful.

On the strengths: it is written in TypeScript and published with support for both CommonJS and ESM. It is isomorphic, working in Node and in modern browsers. The package has been maintained for ten years and is mature. It has nearly 500 tests and is used in production apps of various sizes. It is used by Mailchimp Open Commerce, and by the Collection2 and AutoForm Meteor packages.

On the weaknesses: because of all it does, the package is more complex than and slower than some other packages, and the documentation says that based on your needs you should decide whether those tradeoffs are acceptable. It then names simplecheck, joi and yup as packages you might consider instead.

That last part is the most useful thing in the readme for a reader evaluating alternatives, because it tells you the same thing a reviewer would: this is the validator that does the most, and it is not the fastest one.

The installation is one command:

npm install simpl-schema

And there is a warning worth repeating, because there are other npm packages named simpleschema and simple-schema, so make sure you install the right one.

The build, and the versions

The package manifest shows a project that takes its packaging seriously.

The build script removes the dist directory, runs the TypeScript compiler twice with two separate configurations, one for the ESM output and one for CommonJS, and then runs a post-build shell script. The manifest has separate main, module and types entries pointing at the CommonJS build, the ESM build and the declaration file, plus an exports map with import and require conditions.

The engine requirements are node 14.16 or newer and npm 8, and the browserslist field targets more than 0.5 percent usage, the last two versions, Firefox ESR and not dead, so the browser build is a supported target rather than an accident.

The test setup uses mocha with a .mocharc.json, and the scripts include a check target running the compiler with --noEmit, eslint with --fix variants, and a prepublishOnly hook that runs the build. The linting setup is TypeScript-aware eslint with the standard-with-typescript config, plus eslint-plugin-redos, which is worth noting because a validator that processes user-supplied regular expressions is exactly where a catastrophic backtracking bug would live.

The version in the manifest is 0.0.0-development, the placeholder that a release script replaces. The published versions are 3.4.7 from 2026-03-25, 3.4.6 from 2024-02-26 and 3.4.5 from 2024-02-25, and the last push was on 2026-09-13.

Editorial conclusion

Adopt simpl-schema if you are validating user input in a MongoDB application and you want one schema to cover both a plain object and the update document that modifies it, since that is the capability the other validators listed in its documentation do not offer. Do not adopt it if you want the smallest possible validator, since the documentation is explicit that the package is more complex and slower than some alternatives because of everything it does. Before you install, check three things: that you install simpl-schema and not simpleschema or simple-schema, since all three exist on npm, the Node version, since the manifest requires node 14.16 or newer, and how the autoValue feature behaves in your context, since the documentation has a section of its own on autoValue gotchas.

Frequently asked questions

Official sources

1. License: MIT
2. longshotlabs/simpl-schema on GitHub
3. Project website
4. README
5. Releases