I think most of the time, between updates, a cleaning(delete content) of the local .meteor folder is required, or at least removal of the previous builds with the previous version of Meteor. I think the DB reset is not an actual delete records in the DB but a consequence of emptying the .meteor local folder.
I guess when you try to start the project after a Meteor version update, Meteor sees it has a build and tries to start it up but the build is incompatible with the new version (or new file names/paths). This is just wild guessing, the point being that a fresh new rebuild starting from an empty folder seems to fix the issues.
A suggestion I’d like to share… we’ve invested heavily in a very robust fixtures.js script that completely rebuilds all our test data when a clean database is detected. We maintain the file every time we add a new feature or something that will need test data. Makes dropping the database and starting over a breeze.
I will add some tips about our migration path. We develop severall apps per year, so we have a private meteor (atmosphere, but private) package and a starter app that we use for every new projects.
It’s meteor + React 18
During the last days, we were able to complete the migration to 3.0-rc2 of this starter app!
Here are the hints that may help you moving forward:
We started with a fresh meteor 3.0-rc2 app (using meteor create) and added our private package into this app, and fixed all the conflicts one by one:
we moved back from npm simpl-schema to the meteor version aldeed:simple-schema@1.13.1
we pinned some pakages version like aldeed:collection2@4.0.2-beta.1
we forked universe:i18n and proposed a PR, but it’s not yet accepted so we rely on the fork for now by cloning the repo locally in packages folder
rewrote a bunch of find, update etc to async versions
moved from cultofcoders:grapher to @bluelibs/nova (see here how we dit it), enabling the removal of herteby:denormalize and matb33:collection-hooks that are not yet compatible with Meteor 3
Back to our starter app:
rewrote a bunch of find, update etc to async versions
removed dependency to herteby:denormalize, matb33:collection-hooks, zuuk:stale-session and montiapm:agent, we may re-add some of them later on.
We have lost some features, but I’m sure we will be able to replace them in the months to come.
Our next step is to double check the deployment of this Meteor 3.0 app
matb33:collection-hooks@1.4.0-beta.1 seems to be quite good with meteor 3, have you tried it ?
Why move back from npm simpl-schema to the meteor version aldeed:simple-schema@1.13.1 ? I am asking this because we still import Simple Schema like this in our app : import SimpleSchema from 'simpl-schema' should we change this to import SimpleSchema from "meteor/aldeed:simple-schema" ?
I haven’t tried yet the updated version of collection-hooks, it was not our priority, so I prefered to remove it totally at the moment. We may re-add it later on
We moved back to the meteor version because we have seen somewhere that the npm version won’t support many of the async calls… See here and here
Final tips after successfull deployment of a meteor 3.0-rc.2
slate-serializers broke the build, we had to remove it
tailwind, postcss, postcss-load-config and autoprefixer must be in dependencies and not devDependencies - this hint is somewhere in the forums but not in the official tailwind website
debugging the build is quite difficult because everyhting was smooth locally…
Here is the dedicated topic : Meteor 3.0-rc2 build has errors
I had no problem in dev mode but the build failed. I have to run a lot a builds to find which part was causing it to break (I didn’t see any hint in the error messages)
