Post Your Tips for Updating to Meteor V3

3.0 migration
12

Better to create a new topic or a new issue in github as the error looks like a bug

13

I will list some steps that I took to update Galaxy to the latest Meteor 3 version available:

  • Upgraded to the latest Meteor 2.X version
  • Updated all MongoDB methods to use the Async suffix
    • This will result in updating a lot of code to handle the async await syntax

This will make it easier to migrate to Meteor 3 since you won’t have problems related to the async await and MongoDB methods.

  • While updating to Meteor 3.X, I removed the node_modules and package-lock.json, and ran meteor reset, so I make sure everything was clean. meteor npm install to install all dependencies using the node v20 from Meteor 3.X
  • You will probably face some package constraints. For those, you need to address them individually. You can always override a package; read here how to do it.

I hope that helps. If you have other questions that are not related to non-core packages, I’m here to help.

4 Likes
14

I hope there is a version of meteor reset that does not clear MongoDB. For actual development, the majority of devs do not want to drop their database because of the custom test data that we are using for development.

1 Like
15

What’s your suggestion?
Maybe a flag would be nice? meteor reset --no-db-reset or meteor reset --no-database-reset

2 Likes
16

Since this is too destructive to a development flow (sometimes preparing test data is too complex), I suggest the default meteor reset to be without flushing the db

And with parameter with the db: meteor reset --with-db

3 Likes
17

Normally meteor reset being needed indicates a bug in Meteor or a build plugin. I keep seeing it mentioned when people update to Meteor 3. Are there any specific issues people have run into that it was needed for?

1 Like
18

There are two easy ways to do this

  1. By running a local MongoDB server. This is preferable especially if one runs multiple Meteor projects locally at the same time with shared DBs between projects.
  2. Do reset via NPM script with MongoDB command line DB tools installed. Something like this:
"dump": "mongodump && meteor reset"

This creates a copy of the local DB to a folder called ‘dump’ in the root (or where it is preferred by the developer). This can be restored manually or within the script.

1 Like
19

It depends on how the meteor team wanted to push for this command:

Do these multiple steps

OR

Execute this simple command line

Every time someone mentions meteor reset here in the forum, someone must always warn the developer about his development database (or sorry, I forgot to mention. just rebuild your test data)

1 Like
20

I think the documentation is clear about what it does: Command Line | Meteor API Docs

I am not saying this should not be part of Meteor but just saying that there are easy ways to get things done.

21

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.

22

For everyone’s benefit, this was discussed before by the original proponents of Meteor

From that thread, you can see how many times the feature has been requested before :sweat_smile:

1 Like
23

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.

3 Likes
24

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

2 Likes
25

Hello,
Thanks for sharing your progress.

2 remarks/questions :

  1. matb33:collection-hooks@1.4.0-beta.1 seems to be quite good with meteor 3, have you tried it ?
  2. 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" ?

Edit : I have just read the readme here : GitHub - Meteor-Community-Packages/meteor-collection2: A Meteor package that extends Mongo.Collection to provide support for specifying a schema and then validating against that schema when inserting and updating. . Apparently the npm package is not needed anymore with version 4 of aldeed:collection2

26

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

27

Thanks I will do it then

28

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…

1 Like
29

Could you please provide more context/detail?

30

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)

1 Like
31

Following up on this one:

  • The command meteor reset now requires --db option to reset the database [PR]
3 Likes