meteor-simple-schema: schema validation and cleaning for Meteor, now on promises

SimpleSchema validates and cleans, and the cleaning step is the unusual part

SimpleSchema validates JavaScript objects to ensure they match a schema, and it can also clean those objects, automatically converting types, removing unsupported properties and adding automatic values so that the object is then more likely to pass validation. That second half is what separates this approach from a plain validator. Cleaning is a transformation that happens before validation, so an object that arrives with the wrong types or with extra keys comes out the other side as something that satisfies the schema rather than as an error message. The package sits in the Meteor ecosystem, with package.js at the root of the repository describing the package and a lib directory holding the implementation, tests in a tests directory and a .versions file for Meteor's own dependency pinning. The primary language is JavaScript and the licence is MIT.

The features that decide whether this package beats the alternatives

The README lists the reasons it gives for choosing this package over similar validation libraries. It is isomorphic, working on both server and client. The object you validate can be a MongoDB modifier, and SimpleSchema understands how to validate it such that the object in the database, after modification, will be valid, which is a specific problem that a validator written for plain objects does not solve. Tracker reactivity is optional. The error message system is customizable, with decent English language defaults and support for localization, which is what makes it practical to drop into an app and show messages to end users. The package is also used by the Collection2 and AutoForm Meteor packages, so form generation and collection writing can share one schema definition. The README is honest about the cost, stating that because of everything it does the package is more complex and slower than some others, and that you should decide whether those tradeoffs are acceptable for your needs.

Version 3 turned validation into something you can await

The headline change is the 3.x line, published as v3.0.0 on 2026-06-07, and it is a breaking release. The clean method, the validate method, validation-context validate, validator functions, autoValue, custom validators and whole-document validators may now use promises. That is a substantial change in the calling convention, because a validator that used to be a plain function returning a boolean or a string can now be asynchronous and return a promise. Two things are deliberately unchanged. Calls to isValid and validationErrors remain synchronous and report the last completed validation result, so a caller can still read the previous outcome without awaiting anything. And the package is explicitly not compatible with collection2 4.x.x or autoform 8.x.x or lower, which is the practical constraint on any upgrade plan. The previous release, v2.0.0, dates from 2024-11-21, and v1.13.1 from 2023-12-21, so the gap between 2 and 3 is where most of the churn sits.

Schema keys and rules are declared, and the rule set is large enough to matter

The schema surface is built from keys and rules, and the table of contents in the documentation shows how much of it there is. Definition styles include shorthand definitions, longhand definitions, mixing the two, more shorthand variants, multiple definitions for one key, extending schemas with an option for overriding when extending, subschemas, extracting schemas, and a raw definition form. The rule set per key covers type, label, optional, required, min and max, exclusiveMin and exclusiveMax, minCount and maxCount, allowedValues, regEx, a skipRegExCheckForEmptyStrings switch, blackbox, trim, custom, defaultValue and autoValue, including a documented list of autoValue gotchas, plus function properties and a way to read field properties back. There is also a custom validation path layered on top of the declarative rules: custom field validation, custom whole-document validators, manually adding a validation error, and asynchronous custom validation on the client. That last one is the capability that the 3.x promise support exists to serve.

Validation contexts are how you validate the same schema in different situations

The validation model has two dimensions that trip people up on first contact: what you validate, and how you validate it. Named validation contexts let you attach a modifier, a filter and a validation option to a context name, so a single schema can be validated differently depending on whether you are inserting, updating or checking something else, and the named context is what you then use in code. Unnamed validation contexts are the lighter form. Within a context you can validate a whole object, validate only some keys in an object, and pass validation options such as whether to clean, whether to filter, and whether to replace a modifier. The package also offers throwing validation errors rather than collecting them, with a documented way to customize the error that is thrown, and a way to get back a list of invalid keys together with their messages. That is the API a form or a method argument check actually consumes.

Adding the package, and where the installation details actually live

This is a Meteor package rather than a standalone library, so it is added through the Meteor package system rather than installed with a JavaScript package manager, and the documentation carries a section on installation alongside a section on lingo, which is the localisation support for error messages. The repository itself is the reference for the package definition: package.js at the root declares the package metadata and its dependencies, lib holds the source, tests holds the test suite, and .versions records the resolved versions Meteor pins for the project. The README links onward to the SimpleSchema documentation and to the history of SimpleSchema for the wider background. The stated toolchain for contributors is visible in the repository layout as well, with a lint-test-publish workflow badge and a CodeQL code scanning workflow badge, both under .github, plus a markdownlint configuration and a prettier ignore file.

Where this is the wrong choice, and what simplecheck does instead

Two failure modes are worth naming. The first is version coupling, which is not hypothetical here. A Meteor app that pins collection2 4.x or autoform 8.x or lower cannot move to version 3 of this package without moving those too, and because form generation and collection writing sit on top of SimpleSchema, the upgrade touches the parts of an app that touch forms and database writes, not just the parts that validate objects. The second is performance and complexity, which the README raises itself. Because the package handles cleaning, filtering, modifiers, custom validators, whole-document validators, error message generation and localisation, it does more work per validation than a leaner library, and it does that work on both server and client. The named alternative is simplecheck, described as faster but with fewer features. The trade is direct: less automatic type conversion and property stripping, less control over error messages, and no MongoDB modifier awareness, in exchange for less overhead. For a form on a single collection with a handful of fields, that is often the right call. For an app where one schema drives forms, method arguments and collection writes, the extra machinery pays for itself.

The community fork exists for Meteor compatibility, and that is the real story

The repository is under the Meteor-Community-Packages organisation, and the README states that the package is back under maintenance by that group after being unmaintained, framing the change as a hard fork intended to secure future-proof maintenance with a focus on Meteor compatibility across Meteor 2.x, 3.x and beyond. That is the context that matters for anyone considering the package today. The project status badge in the README marks it as active, the repository is not archived, and the last push was on 2026-07-05. The licence is MIT, so there are no obligations attached to using it in a commercial application. The practical upgrade question for an existing user is not whether the fork is healthy but whether the version 3 promise change can be absorbed in your code, because the compatibility statement rules out the older collection2 and autoform versions and the calling convention for clean and validate has changed underneath you.

Editorial conclusion

meteor-simple-schema suits a Meteor application that already wants one schema definition to drive validation, form generation and collection writes, and that values the ability to validate a MongoDB modifier rather than only a plain object. It does not suit an application still on collection2 4.x or autoform 8.x or lower, since version 3 explicitly breaks compatibility with those, and it does not suit a project that wants the smallest possible dependency. Before you upgrade, check which collection2 and autoform versions your app pins, since the upgrade path runs through both, and read the release note on promise-based validation so that code which relied on clean throwing synchronously is rewritten before the upgrade lands.

Frequently asked questions

Official sources

1. License: MIT
2. Meteor-Community-Packages/meteor-simple-schema on GitHub
3. Project website
4. README
5. Releases