[SOLVED] TypeError: _objectSpread is not a function

My app has been down for three days now, I’m kind of desperate.

I started seeing “Scss compiler error: Error: _includePaths is not iterable” errors locally a few days after I upgraded from Meteor 1.8.1 to 1.10.1. I’m not sure if that’s the cause though, because I had been able to run 1.10.1 just fine before locally (see further).
As explained in this Github issue, I symlinked the packages I needed (bootstrap and photoswipe) and replaced all import rules in my scss files. Example:

-@import "{}/node_modules/bootstrap/scss/_functions.scss";
-@import "{}/node_modules/bootstrap/scss/_variables.scss";
+@import '../../imports/bootstrap/scss/_functions.scss';
+@import '../../imports/bootstrap/scss/_variables.scss';

As soon as I did that, the following error popped up instead of the _includePaths one:

Exception from task TypeError: _objectSpread is not a function
    at Function.Log.<computed> [as error] (packages/logging/logging.js:173:8)
    at packages/webapp/webapp_server.js:615:13
    at runWithEnvironment (packages/meteor.js:1286:24)
    at Object.task (packages/meteor.js:1299:14)
    at Meteor._SynchronousQueue.SQp._run (packages/meteor.js:917:16)
    at packages/meteor.js:894:12
(STDERR) /Users/myuser/.meteor/packages/meteor-tool/.1.10.1.hmdlyt.9z6em++os.osx.x86_64+web.browser+web.browser.legacy+web.cordova/mt-os.osx.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:313
(STDERR) 						throw(ex);
(STDERR) 						^
(STDERR) 
(STDERR) TypeError: _objectSpread is not a function
(STDERR)     at Function.Log.<computed> [as error] (packages/logging/logging.js:173:8)
(STDERR)     at packages/webapp/webapp_server.js:615:13
(STDERR)     at runWithEnvironment (packages/meteor.js:1286:24)
(STDERR)     at Object.task (packages/meteor.js:1299:14)
(STDERR)     at Meteor._SynchronousQueue.SQp._run (packages/meteor.js:917:16)
(STDERR)     at packages/meteor.js:894:12

I can’t find anything about “_objectSpread is not a function” so I have no idea what could be wrong.

I’ve been messing with my setup the last few days because my production environment went down after a release (I still haven’t been able to fix it). That’s why it’s hard to backtrace what the exact reason for this issue might be. Although most of them are probably not related, here’s some of the things I did:

  • I upgraded from Meteor 1.8.1 to 1.10.1 in my dev environment + ran “npm update”. Everything worked fine locally, but when I released to production the app crashed due to this issue.
    • The differences in .meteor/versions and package.json are attached as screenshots
  • I npm removed bcrypt because of this issue that was driving me crazy.
  • When I try downgrading scss:fourseven (meteor add fourseven:scss@=4.10.0) I get an error very similar to the one reported here. Full stack trace is here

I honestly don’t know where to look anymore to fix this.
Do you have an idea of what I can do/where I should look?

Thanks a million and stay safe!


1 Like

PS I tried removing node_modules & package-lock.json already, as well as meteor reset

@babel/runtime is required in your npm dependencies

Thanks for your reply, @rjdavid!

@babel/runtime is part of the dependencies, see the full list here:

"dependencies": {
    "@azure/storage-blob": "^12.1.1",
    "@babel/runtime": "^7.9.2",
    "@iconfu/svg-inject": "^1.2.3",
    "@sentry/browser": "^4.5.2",
    "@sentry/node": "^4.5.2",
    "animate.css": "^3.7.0",
    "axios": "^0.19.2",
    "babel-runtime": "^6.26.0",
    "bootstrap": "^4.4.1",
    "bootstrap-multiselect": "^0.9.13",
    "cookieconsent": "^3.1.0",
    "core-js": "^2.6.11",
    "dinero.js": "^1.8.0",
    "fb": "^2.0.0",
    "fibers": "^3.1.1",
    "googleapis": "^30.0.0",
    "jquery": "^3.4.1",
    "lodash": "^4.17.11",
    "lodash-move": "^1.1.1",
    "messenger-hubspot": "^1.5.0",
    "meteor-node-stubs": "^0.4.1",
    "mollie-api-node": "^1.4.0",
    "moment": "^2.23.0",
    "papaparse": "^4.6.2",
    "phantomjs-prebuilt": "^2.1.16",
    "photoswipe": "^4.1.2",
    "popper.js": "^1.16.1",
    "qs": "^6.9.2",
    "quill": "^1.3.6",
    "sortablejs": "^1.10.2",
    "sparkpost": "^2.1.3",
    "tether": "^1.4.5",
    "twix": "^1.2.0"
  },
  "devDependencies": {
    "@meteorjs/eslint-config-meteor": "^1.0.5",
    "babel-eslint": "^10.1.0",
    "cypress": "^3.8.3",
    "cypress-promise": "^1.1.0",
    "eslint": "^5.11.0",
    "eslint-config-airbnb": "^17.1.0",
    "eslint-import-resolver-meteor": "^0.4.0",
    "eslint-plugin-import": "^2.20.1",
    "eslint-plugin-jsx-a11y": "^6.1.2",
    "eslint-plugin-meteor": "^5.1.0",
    "eslint-plugin-react": "^7.19.0"
  }

Cannot think of any issue

Aside from these basic things.

In local:
meteor npm install

In production:
meteor npm ci

Also, I personally avoid npm update as you are inviting headaches when using it. I use version lens and when an updated npm package is available, I do check for the changes just to be sure that I am aware of potential issue. And if something happens, I have an idea where to look at

1 Like

I usually run npm install without the meteor prefix. That didn’t give me any errors.
When I add meteor I get an error regarding node-gyp, similar to the one I saw in production after the upgrade. I followed these instructions to install node-gyp locally (macOS 10.15.4) and had to upgrade fibers as well to work with node v12. Now I can run meteor npm install without an issue, but I still see the _objectSpread is not a function error.

Didn’t hear about npm ci before, thanks for the tip!

That is definitely good advice, and something I should have known by now (learn it the hard way right). It’s just so tempting to have everything at its latest version :smile:Version Lens looks great actually, but I’m on IntelliJ. Will look out for a similar plugin.

Thanks a lot for your help, @rjdavid!
Do you have any more ideas?

Unless you are specifically making your own native addons you shouldn’t be installing node-gyp directly. Doing so can lead to a whole quagmire of installation issues.

And the reason you should be using meteor npm is that it ensures that all dependencies installed are compatible with the exact meteor/node version used by your app.

Neither of these should be the issue however. The babel pass when building should be including _objectSpread automatically, so there might be a babel issue?
Have you got a .babelrc file in your project or babel key in package json?

Thanks, @coagmano!

Ok, I did npm -g uninstall node-gyp again.

I have neither of those.

Ok, turned out I had both @babel/runtime and babel-runtime in my package.json.

I removed the latter, and then got this error: Cannot find module '…/objectSpread2

Then I continued to update @babel/runtime to 7.9.2 and now I get the _objectSpread is not a function error again. Meteor packages babel-compiler and ecmascript are at their latest versions:

babel-compiler@7.5.3
babel-runtime@1.5.0
ecmascript@0.14.3
ecmascript-runtime@0.7.0
ecmascript-runtime-client@0.10.0
ecmascript-runtime-server@0.9.0

Can anyone help? Could it be related that I had both @babel/runtime and babel-runtime? What’s the difference between the two?

Many thanks!

Hi,
I got a similar problem in dev mode, but not in production (also after upgrading to 1.10.1). I finally solved it by removing node_modules and reinstall dependencies with meteor npm install (which you already tried I think…)

Another option is to use your versionning tool (git I presume) to go back in time an clone a clean working version, and then run the meteor upgrade again

After countless hours of reverting, updating, debugging etc. I finally found the culprit.

While I was trying to fix a failing build (because of the updates I was doing), I added a .meteorignore file because I noticed some unnecessary big files were included in the build as well.

I copy-pasted some lines from my .gitignore file, including…

node_modules/

Doh :man_facepalming:
Removing this line fixed the objectSpread error. I’m not sure if this was the only cause, I’m just very happy everything’s working again (with Meteor 1.10.1)!

Thank you all for your suggestions!

1 Like

This is exactly what is recommended when using fourseven:scss. It references the node-gyp manual installation as a “required toolchain”.

This was the culprit for me. Why isn’t this checked by the upgrade routines?

It doesn’t actually require installing node-gyp though, and doing so can create a lot of extra complications.
You should just follow the instructions to install the toolchain so npm can compile the modules