Upgrade from 3.0.3 to 3.0.4 breaks meteor npm install

help
1

I had a working 3.0.3 installation and tried to update it to 3.0.4.

My bash script always does a meteor npm i before running the server, to ensure all packages are ok even if I switch branches.

After upgrading to 3.0.4., I first got the warning that my package-lock.json had an old version and was upgraded. Afterwards, npm i completely failed due to dependency errors.

So I tried to rollback everything back to 3.0.3, by setting my git repo back to the original version. However, this did not help, I am still getting these errors. Even restoring the repo from a Time Machine Backup did not change this.

It seems as if Meteor installed a new version of Node / npm and now always uses this instead of the one shipped with 3.0.3, even if the repo is still on 3.0.3. It seems to be enough to have updated the Meteor tools to 3.0.4 once.

How can I resolve this situation?

2

I was able to resolve the dependency issues. Still wondering why an update of the Meteor CLI causes even older app versions to use a more recent Node version?

3

That seems to have also happened here:

4

That shouldn’t happen, if I remember correctly Meteor should route the node version the specific version the app is using… I don’t think we upgraded Node.js or altered any logic from 3.0.3 to 3.0.4, we will investigate.

1 Like
5

One thing you can try is to completely delete ~/.meteor and reinstall it and see if it behaves properly

1 Like
6

Thanks for the swift response. Highly appreciated. I have re-installed Meteor 3.0.3, but this didn’t help much. It turned out that the root cause was some invalid dependencies that were unnoticed because npm i did not report them until the meteor update installed a new Node version. After I fixed the dependencies (by downgrading from React 18 to 17), I could npm i again and even upgrade the server to 3.0.4.

However, I am still clueless how the first tried update to 3.0.4 forced my app to update the package-lock.json and then got stock in the failing dependency resolving step. Sometimes, npm is a mystery to me. Especially if you don’t even get an error about the dependencies earlier.

7

We normally encounter this error when using

meteor npm (meteor installed npm)

vs

npm (globally installed npm)

And these two are on different npm versions.

8

I want to understand the current status of this issue to assist if there are any problems with the Meteor tool and how it handles versions. @waldgeist, is everything resolved on your side? the issue is marked as solved already.

It’s important to note what @rjdavid mentioned earlier. Meteor includes a specific node and npm version used by its bundler, so your app should match that version. A good practice is to always use meteor npm install instead of npm install. Beforehand, you can check the expected versions by running meteor --version, meteor node --version, and meteor npm --version. Using your global npm in Meteor can trigger the issues you mentioned because it may have a different version than Meteor’s expected, which can alter your package-lock.json file.

Always use meteor npm install, or ensure your global version matches meteor npm --version listed on your project.

9

@nachocodoner Thanks for coming back to this. In the end it turned out that the culprit was my second commit to the project ever. Here’s what I did:

  • Installed the Meteor 3.0.3 React Typescript scaffold using the CLI (first commit)
  • Then added ESLint in this second commit

This lead to this package.json:

{
  "name": "meteor-app",
  "private": true,
  "scripts": {
    "start": "meteor run",
    "test": "meteor test --once --driver-package meteortesting:mocha",
    "test-app": "TEST_WATCH=1 meteor test --full-app --driver-package meteortesting:mocha",
    "visualize": "meteor --production --extra-packages bundle-visualizer",
    "lint": "eslint .",
    "pretest": "npm run lint --silent"
  },
  "dependencies": {
    "@babel/runtime": "^7.20.7",
    "meteor-node-stubs": "^1.2.5",
    "react": "^18.2.0",
    "react-dom": "^18.2.0"
  },
  "devDependencies": {
    "@meteorjs/eslint-config-meteor": "^1.0.5",
    "@types/mocha": "^8.2.3",
    "@types/node": "^18.13.0",
    "@types/react": "^18.0.26",
    "@types/react-dom": "^18.0.10",
    "babel-eslint": "^10.1.0",
    "eslint": "^5.16.0",
    "eslint-config-airbnb": "^17.1.0",
    "eslint-config-react": "^1.1.7",
    "eslint-config-standard": "^12.0.0",
    "eslint-config-standard-react": "^7.0.2",
    "eslint-import-resolver-meteor": "^0.4.0",
    "eslint-plugin-babel": "^5.3.0",
    "eslint-plugin-import": "^2.20.2",
    "eslint-plugin-jsx-a11y": "^6.2.1",
    "eslint-plugin-meteor": "^5.1.0",
    "eslint-plugin-mocha": "^10.5.0",
    "eslint-plugin-node": "^8.0.1",
    "eslint-plugin-promise": "^4.0.1",
    "eslint-plugin-react": "^7.12.4",
    "eslint-plugin-standard": "^4.0.0"
  },
  "meteor": {
    "mainModule": {
      "client": "client/main.tsx",
      "server": "server/main.ts"
    },
    "testModule": "tests/main.ts"
  }
}

I don’t why, but the usual “typescript” dev dependency in the scaffold vanished here, I can’t remember that I had removed this intentionally.

Important to mention here is that when doing this step, I must have inadvertedly used regular npm i instead of meteor npm i. This caused the package-lock.json file version to be downgraded from 3 to 1, as I can see in my commits.

This went unnoticed, and the setup worked just fine on my local machine, I added more and more npm packages, without any complaints by npm. Until several months later, when I updated Meteor to 3.0.4. Suddenly, I got the message that Node was upgrading the package-lock.json file (again).

And this lead into a kind of deadlock, because all of the sudden, npm realized that I had introduced peer dependencies that could not be resolved. After hours of analyzing the root cause, I found out that the culprit was this combination:

    "react": "^18.2.0",
    "react-dom": "^18.2.0",
    "eslint-plugin-react-hooks": "^5.0.0",

which lead to lots of follow-up errors.

I managed to resolve this by downgrading to

    "react": "^17.0.2",
    "react-dom": "^17.0.2",
    "eslint-plugin-react-hooks": "^4.6.2",

After changing these dependencies (and adjusting my code to the older react-dom), I was able to meteor npm i again.

My lessons learned: Always try to keep an eye on not using npm i by any means. I wasn’t aware that hits can have to drastic consequences that stay unnoticed for months.

Hope this helps you to assess the situation.

(Not sure if I should re-add the typescript package.)

10

I suggest you going back to the point where the package-lock.json version was downgraded from 3 to 1 in your version control. Retrieve the package-lock.json file before this change, and add it to your current branch. Reinstall then using meteor npm install. This will restore your stable package-lock state and properly apply any new dependencies.

If the file is corrupted during npm migration, it may behave incorrectly. One option is to recreate the package-lock.json file, but this may update to newer versions or a incompatible state. Restoring the old state and reinstall might be a better solution.