Post Your Tips for Updating to Meteor V3

3.0 migration
1

This thread is for helpful tips about updating to Meteor v3. I’ll kick it off. Of course, these may be well-known already to many. And if there are better ways, or improvements, please post them.

  • You many find lots of npm package conflicts. My app had so many conflicts, given one or two package updates I wanted, that npm wouldn’t install a single package from my old package json. The approach I used for this, was to get a list of all my npm packages, with version numbers omitted, so that meteor npm install updates everything to the latest version. E.g.

meteor npm install @apollo/client @breejs/later @culturehq/add-to-calendar @date-io/date-fns @date-io/moment @emotion/react @emotion/styled @fvilers/disable-react-devtools @maxmind/geoip2-node @mui/icons-material @mui/lab @mui/material [.....]

Needless to say, there are probably going to be some breaking changes to deal with.

3 Likes
2

Here’s another one. Here’s the code I use to dump/restore Mongo.

  • Launch the Meteor v2.x version of your app.
  • Run mongodump --uri="mongodb://localhost:3001/meteor"
  • Stop the Meteor v2.x version of your app
  • Find the folder that contains the exported mongo files, e.g. “meteor_accounts_loginServiceConfiguration.bson”, “meteor_accounts_loginServiceConfiguration.metadata”, etc.
  • rename that folder, “dump”
  • cd to directory that contains that dump folder
  • launch your Meteor 3 app
  • run mongorestore --uri="mongodb://localhost:3001/meteor"
3

I’m never a fan of “blindly updating and hoping it works” route. From experience, that can result to more work and technical debts that you have to work on in the future (especially when you are not prepared).

  1. Use exact version of npm packages in package.json

  2. Use version lens extension (vscode) to know which packages have updates

1 Like
4

You probably are more skilled at this than I am.

I usually take the approach you described also. Update a package, research the breaking changes, and test thoroughly.

In this case, I used meteor npm outdated to see what needed to be updated, but doing those updates alone didn’t work because of dependencies of included packages. I deleted the node_modules folder first. Then meteor npm update wouldn’t install a single package.

I was looking at this and couldn’t figure out what to update in what order:

npm ERR! code ERESOLVE
npm ERR! ERESOLVE could not resolve
npm ERR! 
npm ERR! While resolving: [at]apollo/react-common[at]3.1.4
npm ERR! Found: graphql[at]16.8.1
npm ERR! node_modules/graphql
npm ERR!   graphql[at]"^16.8.1" from the root project
npm ERR!   peer graphql[at]"14.x || 15.x || 16.x" from [at]apollo/cache-control-types[at]1.0.3
npm ERR!   node_modules/[at]apollo/cache-control-types
npm ERR!     [at]apollo/cache-control-types[at]"^1.0.3" from [at]apollo/server[at]4.10.4
npm ERR!     node_modules/[at]apollo/server
npm ERR!       [at]apollo/server[at]"^4.10.4" from the root project
npm ERR!   39 more ([at]apollo/client, [at]apollo/server, ...)
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer graphql[at]"^14.3.1" from [at]apollo/react-common[at]3.1.4
npm ERR! node_modules/[at]apollo/react-common
npm ERR!   [at]apollo/react-common[at]"^3.1.4" from the root project
npm ERR!   [at]apollo/react-common[at]"^3.1.4" from [at]apollo/react-components[at]3.1.5
npm ERR!   node_modules/[at]apollo/react-components
npm ERR!     [at]apollo/react-components[at]"^3.1.5" from [at]apollo/react-hoc[at]3.1.5
npm ERR!     node_modules/[at]apollo/react-hoc
npm ERR!       [at]apollo/react-hoc[at]"^3.1.5" from react-apollo[at]3.1.5
npm ERR!       node_modules/react-apollo
npm ERR!     1 more (react-apollo)
npm ERR!   4 more ([at]apollo/react-hoc, [at]apollo/react-hooks, ...)
npm ERR! 
npm ERR! Conflicting peer dependency: graphql[at]14.7.0
npm ERR! node_modules/graphql
npm ERR!   peer graphql[at]"^14.3.1" from [at]apollo/react-common[at]3.1.4
npm ERR!   node_modules/[at]apollo/react-common
npm ERR!     [at]apollo/react-common[at]"^3.1.4" from the root project
npm ERR!     [at]apollo/react-common[at]"^3.1.4" from [at]apollo/react-components[at]3.1.5
npm ERR!     node_modules/[at]apollo/react-components
npm ERR!       [at]apollo/react-components[at]"^3.1.5" from [at]apollo/react-hoc[at]3.1.5
npm ERR!       node_modules/[at]apollo/react-hoc
npm ERR!         [at]apollo/react-hoc[at]"^3.1.5" from react-apollo[at]3.1.5
npm ERR!         node_modules/react-apollo
npm ERR!       1 more (react-apollo)
npm ERR!     4 more ([at]apollo/react-hoc, [at]apollo/react-hooks, ...)

Here’s what my package.json looked like at the time:

{
“name”: “my app”,
“private”: true,
“version”: “1.0.0”,
“scripts”: {
“start”: “meteor run”
},
“devDependencies”: {
“[at]meteorjs/eslint-config-meteor”: “^1.0.5”,
“babel-eslint”: “^10.1.0”,
“caniuse-lite”: “^1.0.30001620”,
“eslint”: “^8.57.0”,
“eslint-config-airbnb”: “^19.0.4”,
“eslint-import-resolver-meteor”: “^0.4.0”,
“eslint-plugin-import”: “^2.29.1”,
“eslint-plugin-jsx-a11y”: “^6.8.0”,
“eslint-plugin-meteor”: “^7.3.0”,
“eslint-plugin-react”: “^7.34.1”
},
“dependencies”: {
“-”: “0.0.1”,
“[at]apollo/react-common”: “^3.1.4”,
“[at]apollo/client”: “^3.10.4”,
“[at]apollo/server”: “^4.10.4”,
“[at]breejs/later”: “^4.2.0”,
“[at]culturehq/add-to-calendar”: “^1.1.2”,
“[at]date-io/date-fns”: “^2.17.0”,
“[at]date-io/moment”: “^2.17.0”,
“[at]emotion/react”: “^11.11.4”,
“[at]emotion/styled”: “^11.11.5”,
“[at]fvilers/disable-react-devtools”: “^1.3.0”,
“[at]graphql-tools/schema”: “^10.0.3”,
“[at]maxmind/geoip2-node”: “^5.0.0”,
“[at]mui/icons-material”: “^5.15.18”,
“[at]mui/lab”: “^5.0.0-alpha.170”,
“[at]mui/material”: “^5.15.18”,
“[at]mui/styles”: “^5.15.18”,
“[at]mui/system”: “^5.15.15”,
“[at]mui/x-date-pickers”: “^6.19.9”,
“[at]types/react”: “^16.14.60”,
“[at]use-it/event-listener”: “^0.1.7”,
“agora-rtc-sdk-ng”: “^4.20.2”,
“apollo-cache-inmemory”: “^1.6.6”,
“apollo-client-preset”: “^1.0.8”,
“apollo-graphql”: “^0.9.7”,
“apollo-link-ddp”: “^3.0.0”,
“apollo-link-error”: “^1.1.13”,
“apollo-link-ws”: “^1.0.20”,
“apollo-server”: “^3.13.0”,
“apollo-server-core”: “^3.13.0”,
“axios”: “^1.6.8”,
“babel-plugin-inline-import”: “^3.0.0”,
“babel-runtime”: “^6.26.0”,
“bcrypt”: “^5.1.1”,
“body-parser”: “^1.20.2”,
“braintree”: “^3.23.0”,
“braintree-web”: “^3.102.0”,
“braintree-web-drop-in”: “^1.42.0”,
“braintree-web-drop-in-react”: “^1.2.1”,
“calendar-link”: “^2.6.0”,
“compress”: “^0.99.0”,
“cors”: “^2.8.5”,
“date-fns”: “^2.30.0”,
“date-fns-timezone”: “^0.1.4”,
“date-fns-tz”: “^2.0.1”,
“dayjs”: “^1.11.11”,
“deep-diff”: “^1.0.2”,
“downshift”: “^8.5.0”,
“email-validator”: “^2.0.4”,
“emoji-picker-react”: “^4.9.2”,
“express”: “^4.19.2”,
“formik”: “^2.4.6”,
“framer-motion”: “^10.18.0”,
“fs”: “0.0.1-security”,
“graphql”: “^16.8.1”,
“graphql-scalars”: “^1.23.0”,
“graphql-subscriptions”: “^2.0.0”,
“graphql-tag”: “^2.12.6”,
“graphql-type-json”: “^0.3.2”,
“helmet”: “^6.2.0”,
“http-proxy”: “^1.18.1”,
“ics”: “^3.7.2”,
“immutability-helper”: “^3.1.1”,
“jstimezonedetect”: “^1.0.7”,
“lodash”: “^4.17.21”,
“logrocket”: “^7.0.0”,
“lozad”: “^1.16.0”,
“meteor-node-stubs”: “^1.2.9”,
“node-rsa”: “^1.1.1”,
“pg”: “^8.11.5”,
“pubsub”: “^3.2.1”,
“qrcode”: “^1.5.3”,
“raw-body”: “^2.5.2”,
“react”: “^18.3.1”,
“react-apollo”: “^3.1.5”,
“react-cache”: “^2.0.0-alpha.1”,
“react-dom”: “^18.3.1”,
“react-ga4”: “^2.1.0”,
“react-gtm-module”: “^2.0.11”,
“react-helmet”: “^6.1.0”,
“react-hook-form”: “^7.51.4”,
“react-intersection-observer”: “^9.10.2”,
“react-lazyload”: “^3.2.1”,
“react-mounter”: “^1.2.0”,
“react-router-dom”: “^6.23.1”,
“react-swipeable”: “^7.0.1”,
“react-use”: “^17.5.0”,
“request”: “^2.88.2”,
“rough-notation”: “^0.5.1”,
“save”: “^2.9.0”,
“scroll-into-view-if-needed”: “^3.1.0”,
“scroll-to-element”: “^2.0.3”,
“sequelize”: “^6.37.3”,
“smooth-scroll-into-view-if-needed”: “^2.0.2”,
“stopword”: “^2.0.8”,
“subscriptions-transport-ws”: “^0.11.0”,
“twilio”: “^4.23.0”,
“underscore”: “^1.13.6”,
“uploadcare-widget”: “^3.21.2”,
“vary”: “^1.1.2”,
“webfontloader”: “1.6.28”,
“ws”: “^8.17.0”,
“xml-js”: “^1.6.11”,
“yup”: “^1.4.0”
}
}

Note: “@” has been replaced with “[at]” because the forum sofware thought I was mentioning too many forum users.

Going from node 14 to node 20 can mean a lot of interconnected updates.

5

The error message mentioned peer dependency issues.

I agree. That is why blindly updating can result in not knowing what is happening or whether the problem came from the package, changes in Node, or the incompatibility of both, including the app.

6

What I need is advice on how to not blindly update in this case. How do you determine the correct order of installing packages? I can’t even test them in my app without a large subset of them, since my app requires Apollo/React/MUI to run even the home page.

But please advise. I’m sure I’ll learn something from whatever you say.

7

You can either:

Check the error message you posted above for the required version of peer dependency packages you need to install

OR

Check the peer dependency requirements of the packages that you are installing

8

I want to set up Google login with Meteor v3 and get this error. bellow is my seetings and error: After changing all findOne to findOneAsync.

const settings = Meteor.settings || {};

Meteor.startup(async () => {
const googleClientId = settings?.private?.google?.clientId;
const googleSecret = settings?.private?.google?.secret;
console.log(‘Google Secret:’, googleSecret);

if (!googleClientId || !googleSecret) {
throw new Error(‘googleClientId and googleSecret are required’);
}

await ServiceConfiguration.configurations.upsertAsync(
{ service: ‘google’ },
{
$set: {
clientId: googleClientId,
secret: googleSecret,
loginStyle: ‘redirect’,
requestPermissions: [‘profile’, ‘email’],
},
}
);
});

Exception while invoking method ‘login’ Error: findOne + is not available on the server. Please use findOneAsync() instead.
I20240520-02:17:24.866(-4)? at Object.ret. [as findOne] (packages/mongo/remote_collection_driver.js:52:15)
I20240520-02:17:24.872(-4)? at Collection.findOne (packages/mongo/collection.js:559:29)
I20240520-02:17:24.872(-4)? at getTokens (packages/google-oauth/google_server.js:128:54)
I20240520-02:17:24.873(-4)? at Object.getServiceData [as handleOauthRequest] (packages/google-oauth/google_server.js:169:34)
I20240520-02:17:24.873(-4)? at OAuth._requestHandlers. (packages/oauth2/oauth2_server.js:10:39)
I20240520-02:17:24.873(-4)? at middleware (packages/oauth/oauth_server.js:170:11)
I20240520-02:17:24.874(-4)? at processTicksAndRejections (node:internal/process/task_queues:95:5)

9
  1. (alternative) Use npm-check-updates.
  2. Setup renovate or dependabot
10

And of course, 3. is useless without automated tests with good enough coverage that run on GitHub Actions or equivalent.

11

Multiple times, we were burned by packages that did not follow semver (Meteor for one :sweat_smile:). But yes, the automated tests with good coverage should handle that issue of a rogue update breaking the build.

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.