Meteor 1.9 / 1.8.2 + Nexe not working anymore

Hey there,

we did an update from Meteor 1.8.1 to 1.9 and now we cannot start our app anymore if we package it with Nexe. There must have been changes from version 1.8.2 onwards that are responsible for breaking something in the Nexe utility. The error looks like this:

…\dist\programs\server\mini-files.js:1*
module.export({*
^*

TypeError: module.export is not a function

  • at Object. (…\output\dist\programs\server\mini-files.js:1:14)*
  • at Module._compile (internal/modules/cjs/loader.js:959:30)*
  • at Object.Module._extensions…js (internal/modules/cjs/loader.js:995:10)*
  • at Module.load (internal/modules/cjs/loader.js:815:32)*
  • at Function.Module._load (internal/modules/cjs/loader.js:727:14)*
  • at Module.require (internal/modules/cjs/loader.js:852:19)*
  • at require (internal/modules/cjs/helpers.js:74:18)*
  • at Object. (…\output\dist\programs\server\boot.js:14:15)*
  • at Object. (…\output\dist\programs\server\boot.js:466:3)*
  • at Module._compile (internal/modules/cjs/loader.js:959:30)*

Do you have any ideas how to fix that?

rka

My first thought is that nexe might have built with the wrong node version as a target?
I’ve never used nexe before so not sure

Check the breaking changes in 1.8.2. There is a note about the use of export and the error seems related

2 Likes

Yes, we recognized the changes but we were not able to solve this issue. It seems to be too much “magic” which is done by tools like reify compiler. This breaks our packaging with Nexe.

We also tried zeit/pkg but it’s even more difficult to combine it with Meteor.

We are not sure if we can continue like that with Meteor. We are frozen at 1.8.1 at the moment. Apparently our setup is not so widespread. We deploy our software only to servers in local networks and therefore need to package it. :neutral_face:

I came across this post while trying to solve the same problem, although my circumstances are slightly different, as I don’t use Nexe. I still believe I have a solution that could also be replicated in your particular case.

For various reasons, I run the Meteor server bundle by directly executing bundle/programs/server/boot.js, with Node. Note: I use the exact Node version that’s otherwise bundled with the particular Meteor release for safety.

The module.export(...) and module.link(...) are reify additions. I looked in boot.js, and mini-files.js gets imported quite early on. It uses the module.export(...) syntax, however there’s no indication as to how Node is suddenly supposed to know what module.export and module.link are.

There’s another file in this same directory, runtime.js. It does exactly what needs to be done (adds reify extensions to the native module prototype). This file is not being imported before we encounter the first module.export(...) call (I guess when not running Meteor manually, this is taken care of). What we therefore need to do is to execute runtime.js before boot.js.

To verify this, add this at the very top of boot.js and see what happens:

require('./runtime');
// **** rest of boot.js *****

Obviously, you should be doing this from outside the compiled Meteor bundle, in the same place you (or Nexe) is running boot.js from. In my case, ignoring other steps, this was the solution:

// Launch the usual Meteor server
require(path.join(serverDir, 'runtime.js'));
require(path.join(serverDir, 'boot.js'));
1 Like

Thanks for your help! @mzeffect

You’re right with your analysis. It seems like running the runtime.js before boot.js became necessary with Meteor 1.8.2. Like you we were using the boot.js directly with Node because we encountered another problem when we gave the main.js as an input to Nexe. There was a missing line somewhere. Luckily this workaround is not necessary anymore with the current version of Meteor.

To summarize… this topic is solved at the moment. :slightly_smiling_face: