Horror Story : "Converting circular structure to JSON"

I have made some major changes to my app over the past month or two, very many commits, without verifying that a production build and deploy is still possible. Development builds have all passed all tests.

Trying a production build today, I get the error shown below repeated three times (one each for the three target environment, browser, mobile & server).

This forum has a half dozen mentions of this error but they’re all different. None appear to happen entirely within BabelCompiler.

Can anyone suggest how I can track down the cause of this?

While processing files with ecmascript (for target os.linux.x86_64):
native: Converting circular structure to JSON
at Object.stringify (native)
at Object.stringify (/home/yourself/.meteor/packages/meteor-tool/.1.5.1-beta.1.co8zwt++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/lib/node_modules/core-js/modules/es6.symbol.js:224:23)
at deepHash (/home/yourself/.meteor/packages/ecmascript/.0.9.0-alpha.6.15nr2zk++os+web.browser+web.cordova/plugin.compile-ecmascript.os/npm/node_modules/meteor/babel-compiler/node_modules/meteor-babel/util.js:27:18)
at Object.exports.deepHash (/home/yourself/.meteor/packages/ecmascript/.0.9.0-alpha.6.15nr2zk++os+web.browser+web.cordova/plugin.compile-ecmascript.os/npm/node_modules/meteor/babel-compiler/node_modules/meteor-babel/util.js:42:10)
at Cache.Cp.get (/home/yourself/.meteor/packages/ecmascript/.0.9.0-alpha.6.15nr2zk++os+web.browser+web.cordova/plugin.compile-ecmascript.os/npm/node_modules/meteor/babel-compiler/node_modules/meteor-babel/cache.js:66:22)
at Object.compile (/home/yourself/.meteor/packages/ecmascript/.0.9.0-alpha.6.15nr2zk++os+web.browser+web.cordova/plugin.compile-ecmascript.os/npm/node_modules/meteor/babel-compiler/node_modules/meteor-babel/index.js:28:23)
at Object.Babel.compile (packages/babel-compiler.js:54:29)
at packages/babel-compiler.js:183:22
at Function.time (/tools/tool-env/profile.js:305:10)
at profile (packages/babel-compiler.js:226:20)
at BabelCompiler.BCp.processOneFileForTarget (packages/babel-compiler.js:182:20)
at BabelCompiler.<anonymous> (packages/babel-compiler.js:114:26)
at Array.forEach (native)
at BabelCompiler.BCp.processFilesForTarget (packages/babel-compiler.js:113:14)
1 Like

Some further details :

This works…

meteor npm install;
meteor build /dev/shm/target/ --server-only --architecture os.linux.x86_64;

This fails with the previously mentioned errors …

meteor npm install --production;
meteor build /dev/shm/target/ --server-only --architecture os.linux.x86_64;

Isn’t the former command the correct one? You’re performing a build, which requires your dev dependencies to properly complete.

1 Like

Hi Nathan

I really appreciate your willingness to help. The problem is that I referred to the Meteor Guide to learn the up-to-date way to prepare for deployment,

Are the instructions here incorrect or out of date? (I mean, they say to use Node 4.6.2, but meteor node --version returns 4.8.3! Do I follow the guide or the code? )

The guide should probably note that any packages you are using to run in development need to be installed when building your app. With the default Meteor project, you shouldn’t need any devDependencies, because none are included when you run meteor create. However, if you have a compiler plugin installed that uses devDependencies, for example a Sass compiler that requires you to install node-sass, or if you are using a custom babel transform plugin, then you will need to run meteor npm install without the --production flag (personally, I’d just always run it without the --production flag).
This of course is assuming that are using devDependencies in your package.json (as opposed to having encountered a bug). :slight_smile:

As for the node version, it depends on your version of Meteor, and the guide is not up-to-date. What the guide should say (and probably does somewhere else, but should also say it here) is to run meteor node --version within your project directory and always match the version of node on your server to that.

1 Like

Nathan, the point of the --production flag is to reduce the size and processing of the deployed app, right? Given that – surely any devDependencies packages needed to run the app during development are specified incorrectly and need to moved to the dependencies section, no?

[quote=“nathantreid, post:6, topic:37723”]
This of course is assuming that are using devDependencies in your package.json (as opposed to having encountered a bug). :slight_smile:
[/quote]Can you spot a package here that ought properly to be in the dependencies section?

"devDependencies": {
    "babel-core": "6.24.1",
    "babel-eslint": "7.2.3",
    "babel-polyfill": "6.23.0",
    "babel-preset-es2015": "^6.24.1",
    "babel-preset-react": "^6.24.1",
    "babel-preset-stage-2": "^6.24.1",
    "chai": "4.0.2",
    "chimp": "0.49.0",
    "enzyme": "2.8.2",
    "eslint": "3.19.0",
    "eslint-plugin-babel": "4.1.1",
    "eslint-plugin-react": "7.0.1",
    "jsdom": "9.12.0",
    "knex": "^0.13.0",
    "mocha": "3.4.2",
    "react-addons-test-utils": "15.5.1",
    "sinon": "2.3.2"
  },
  "dependencies": {
     :     :
    "babel-runtime": "6.23.0",
     :     :
  ,

The problem is clearly with BabelCompiler, but if there are useful hints in the stacktrace above I’m not seeing them. Some incompatibility between packages/babel-compiler.js and meteor/babel-compiler/node_modules/meteor-babel, maybe?

Yup. That’s what I do. I only mentioned that as an example of why I don’t always trust the guide 100%.

knex is the most likely candidate.

I only use knex to set up test data during development. It might be the problem, I’ll certainly try moving it.
However, I don’t see how it could be causing “Converting circular structure to JSON” in BabelCompiler.

I agree - it was just the only package which (to my eyes) looked out of place.

Aha! Typically I learn something new whenever you post here, so you had me asking myself, “Ok, numbskull, what have you misunderstood about the BabelCompiler…hmmm?” :smiley:

Haha. Trust me - I know next to nothing about Babel’s requirements. As long as it works, I’m happy to remain ignorant!

You’re using jsdom for testing? That’s another package which would be at home in production.

Ok, now you really have me wondering … the only reference to jsdom in my code is for Mocha tests. Why do I want that in production?

Ah - just noticed you haven’t listed all your dependencies. I was looking at devDependencies to see if there was anything in those which might be expected in dependencies instead.

My understanding of the Meteor build process is that it doesn’t copy devDependencies into the final app bundle (this change happened sometime after 1.3 was released).
Things like Babel presets that are required to build the app but not to run it once built are typically intended to go in devDependencies. They won’t be included in your final app, but meteor build will fail without them.
In your package.json example, I’d expect the build process to fail if you use meteor npm install --production because I’d assume that your .babelrc is using at least one of those presets. Of course, maybe you’re using them for something outside of your Meteor app (I don’t know your set up), but given the Babel error, that’d be the first place I’d look.

Hey, Nathan.

Sorry for the long delay in replying to you. Summertime here …

So I’m just not going to use the production flag. I thought the point was to ensure devDependencies are kept out, but since, as you state, they don’t get bundled any way, I see no reason to use the flag.

I’m wondering what the flag is for at all, now. Should it be deprecated?

The --production flag is part of the npm install command, and is definitely useful outside of Meteor. For example, if I’ve created an app with webpack instead of Meteor, then to build the app I will want to run npm install followed by the webpack build command. This creates an app bundle, similar to the Meteor bundling process. When I install that bundle on my server, I’ll want to run npm install --production on the server to only install the production dependencies.

So the production flag is great; the Meteor documentation probably just needs updated to either explain when to use the --production flag with meteor npm install, or to not include it at all.

That totally makes sense. Thank you for taking the time to explain it.