Hello,
I am a bit lost with SimpleSchema packages.
I have meteor add’ed aldeed:collection2 v4.1.5. But this one requires aldeed:simple-schema meteor package v2.0, while simpl-schema is available as an independant npm since (years?). Unfortunately I have built my application with this npm which is v3.4. and it seems that having these two versions simultaneously produces weird bugs…
Would you have any suggestion ?
Obvious first one is to remove simpl-schema npm and go back to aldeed:simple-schema v2
Another one is to locally patch collection2 to use the npm (which I have tested and at least fix my bugs). I would be willing to propose a PR but I am not sure if this is the way Meteor guys want go ?
Or maybe there is another solution ?
Hi,
I don’t have yet tried with both MCP packages. This was the first option I have considered above. And yes I could give a try. But as that would imply a back move from SimpleSchema v3.4 to v2, I wanted know what was the strategy from Meteor guys and other developers point of view.
The fact is that I don’t understand the point of having a Meteor package aldeed:simple-schema when the NPM exists and seems to be more advanced. Is this something we keep for historic compatibility ? Or are there other plans to update it sooner ? or what ?
From Claude : The short version: the Atmosphere aldeed:simple-schema and the npm simpl-schema are now two completely separate codebases, maintained by different teams. You should pick one, not use both.
What happened:
Back in 2016, aldeed extracted the core logic from the Atmosphere package into the npm simpl-schema so it could be used outside Meteor. For a while, both worked fine together. But starting with v2/v3, the npm package dropped all Meteor-specific integrations — no more Tracker reactivity, no audit-argument-checks support, no Meteor-aware features.
So MCP hard-forked the last Meteor-compatible version (simpl-schema@1.13.1) back into the Atmosphere package. The current aldeed:simple-schema@2.0.0 is that fork, updated for Meteor 3. It’s fully self-contained — all the code lives in the package, there’s no dependency on the npm simpl-schema at all.
Your situation:
You have two different SimpleSchema constructors in your app. Schemas created with npm simpl-schema are invisible to aldeed:collection2, which only knows about the Atmosphere aldeed:simple-schema. That’s what causes the “weird bugs.”
The fix:
Remove simpl-schema from your npm dependencies
meteor add aldeed:collection2 (which pulls in aldeed:simple-schema@2.0.0 automatically)
Replace all import SimpleSchema from 'simpl-schema' with import SimpleSchema from 'meteor/aldeed:simple-schema'
The API surface is nearly identical (same heritage), so the migration should be mostly mechanical. The main thing you gain back is Tracker reactivity and check() integration.
Since v4.0, aldeed:collection2 ships with aldeed:simple-schema built in. The npm simpl-schema is no longer involved, you can check the actual source: it imports from meteor/aldeed:simple-schema, not from npm
Your fix:
meteor add aldeed:collection2
Remove simpl-schema from npm
Replace import SimpleSchema from 'simpl-schema' with import SimpleSchema from 'meteor/aldeed:simple-schema'
API is nearly identical so it’s mostly a search-and-replace on imports. Just tested on a fresh Meteor 3.4 app, everything works