we can get our app running on osx, but I have a remote dev who is trying to get it running on linux. but he gets this error. Any ideas? Should I just buy him a mac?
20170105-21:03:26.104(-6)? (STDERR)
W20170105-21:03:26.104(-6)? (STDERR) in the root directory of your application.
W20170105-21:03:28.901(-6)? (STDERR) /home/vu/.meteor/packages/meteor-tool/.1.4.2_3.17tso1e++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/server-lib/node_modules/fibers/future.js:280
W20170105-21:03:28.901(-6)? (STDERR) throw(ex);
W20170105-21:03:28.901(-6)? (STDERR) ^
W20170105-21:03:28.901(-6)? (STDERR)
W20170105-21:03:28.901(-6)? (STDERR) TypeError: applyContainerQuery is not a function
W20170105-21:03:28.901(-6)? (STDERR) at meteorInstall.imports.ui.layouts.TopMenuComponent.js (imports/ui/layouts/TopMenuComponent.js:105:36)
W20170105-21:03:28.902(-6)? (STDERR) at fileEvaluate (packages/modules-runtime.js:181:9)
W20170105-21:03:28.902(-6)? (STDERR) at Module.require (packages/modules-runtime.js:106:16)
W20170105-21:03:28.902(-6)? (STDERR) at Module.Mp.import (/home/vu/.meteor/packages/modules/.0.7.7.1m2ukcu++os+web.browser+web.cordova/npm/node_modules/reify/lib/runtime.js:70:16)
W20170105-21:03:28.902(-6)? (STDERR) at meteorInstall.imports.ui.layouts.ConnectedTopMenuComponent.js (imports/ui/layouts/ConnectedTopMenuComponent.js:1:1)
W20170105-21:03:28.902(-6)? (STDERR) at fileEvaluate (packages/modules-runtime.js:181:9)
W20170105-21:03:28.902(-6)? (STDERR) at Module.require (packages/modules-runtime.js:106:16)
W20170105-21:03:28.902(-6)? (STDERR) at Module.Mp.import (/home/vu/.meteor/packages/modules/.0.7.7.1m2ukcu++os+web.browser+web.cordova/npm/node_modules/reify/lib/runtime.js:70:16)
W20170105-21:03:28.902(-6)? (STDERR) at meteorInstall.imports.ui.layouts.ConnectedMasterLayout.js (/home/vu/workspace/blackship/.meteor/local/build/programs/server/app/app.js:12789:2683)
W20170105-21:03:28.902(-6)? (STDERR) at fileEvaluate (packages/modules-runtime.js:181:9)
W20170105-21:03:28.903(-6)? (STDERR) at Module.require (packages/modules-runtime.js:106:16)
W20170105-21:03:28.903(-6)? (STDERR) at Module.Mp.import (/home/vu/.meteor/packages/modules/.0.7.7.1m2ukcu++os+web.browser+web.cordova/npm/node_modules/reify/lib/runtime.js:70:16)
W20170105-21:03:28.903(-6)? (STDERR) at meteorInstall.imports.routes.js (imports/routes.js:1:1)
W20170105-21:03:28.903(-6)? (STDERR) at fileEvaluate (packages/modules-runtime.js:181:9)
W20170105-21:03:28.903(-6)? (STDERR) at Module.require (packages/modules-runtime.js:106:16)
W20170105-21:03:28.903(-6)? (STDERR) at Module.Mp.import (/home/vu/.meteor/packages/modules/.0.7.7.1m2ukcu++os+web.browser+web.cordova/npm/node_modules/reify/lib/runtime.js:70:16)
W20170105-21:03:28.903(-6)? (STDERR) at meteorInstall.imports.render.js (imports/render.js:1:1)
W20170105-21:03:28.903(-6)? (STDERR) at fileEvaluate (packages/modules-runtime.js:181:9)
W20170105-21:03:28.903(-6)? (STDERR) at Module.require (packages/modules-runtime.js:106:16)
W20170105-21:03:28.904(-6)? (STDERR) at Module.Mp.import (/home/vu/.meteor/packages/modules/.0.7.7.1m2ukcu++os+web.browser+web.cordova/npm/node_modules/reify/lib/runtime.js:70:16)
W20170105-21:03:28.904(-6)? (STDERR) at meteorInstall.server.main.js (server/main.js:1:1)
W20170105-21:03:28.904(-6)? (STDERR) at fileEvaluate (packages/modules-runtime.js:181:9)
W20170105-21:03:28.904(-6)? (STDERR) at require (packages/modules-runtime.js:106:16)
W20170105-21:03:28.904(-6)? (STDERR) at /home/vu/workspace/blackship/.meteor/local/build/programs/server/app/app.js:29308:1
W20170105-21:03:28.904(-6)? (STDERR) at /home/vu/workspace/blackship/.meteor/local/build/programs/server/boot.js:295:34
W20170105-21:03:28.904(-6)? (STDERR) at Array.forEach (native)
W20170105-21:03:28.904(-6)? (STDERR) at Function._.each._.forEach (/home/vu/.meteor/packages/meteor-tool/.1.4.2_3.17tso1e++os.linux.x86_64+web.browser+web.cordova/mt-os.linux.x86_64/dev_bundle/server-lib/node_modules/underscore/underscore.js:79:11)
W20170105-21:03:28.905(-6)? (STDERR) at /home/vu/workspace/blackship/.meteor/local/build/programs/server/boot.js:128:5
=> Exited with code: 1
=> Your application is crashing. Waiting for file change.
OK maybe I misunderstand docker. I thought it was more of a platform for hosting. But could we use it for development too? when it comes time to deploy to Galaxy, will Docker get in the way?
Are you sure you are not simply trying to run from different branches of your app?
Meteor goes to great lengths to ensure cross platform repeatable builds unless you have explicit binary dependencies which themselves have platform dependent problems (or you are on windows where anything can go randomly wrong, although a lot of people do run windows for meteor development without any glitches).
Did you try a clean build with meteor reset && rm -rf node_modules && meteor npm install && meteor
But by the looks of it, this is just a javascript error where applyContainerQuery is expected to be a function whereas it is not.
All in all, linux is your target deployment OS anyway since Galaxy provides a linux environment to your app, granted, confined in a docker container, but docker’s value to your development/build/deployment workflow would not be build consistency here because that’s already a baseline you have.
Is it possible for you to paste in the contents of TopMenuComponent.js and if imported from another file, the contents of the file that exports applyContainerQuery possibly from that developer’s computer where I guess it is simply different than yours.
I know it’s crazy. we’ve burned a whole week on this issue. Yes, I’ve blown away node_modules, yes we are on the same version of node, yes we are on the same version of mongo. Yes, the same branch. Yes it runs on 5 different developer machines (all running on Apple hardware). I just bought a new MBP, installed node, git and mongo, pulled the repo, ran npm install and then started the app successfully on my machine. It also runs on several other developer machines, but not on the linux machine of my new contractor.
Oddly, in my own project I get this linting warning which says, ‘react-container-query’ not installed. the typeError (applyContainerQuery) showing up in the other dev’s project is exported from this package.
But I can see it’s clearly in my package.json, it’s in node-modules, and, most importantly, my project runs successfully.
I wonder why the IDE thinks there is some issue with package, and why would it run anyway on my system but not on the dev’s?
one thing is that we’ve been running npm install not meteor npm install so I guess I’ll tell the dev to try and nuke everything and try that.
meteor expects a certain version of node and a certain version of npm and bundles it so that all dev machines are consistent.
if you use npm install instead of meteor npm install, you opt out of using meteor’s node/npm and introduce an inconsistency.
webstrom is also usually very good at spotting deoendency problems with imports therefore I suspect that if you do the cleaning and use meteor npm you’ll get closer to the root cause.
I now suspect that your dev’s computer is running a different version of node and/or npm on their linux than what you are running on your mac.
btw: thinking that one needs to have node/npm installed in order to develop with meteor is a common misconception.
btw: thinking that one needs to have node/npm installed in order to develop with meteor is a common misconception.
yeah, I was always told we need npm therefore we should just install node as that’s an easy way to get npm installed. So should I run all npm commands prefixed with meteor?
Yes it does as long as you prefix node and npm commmands with meteor. It bundles a version of node and npm that’s valid, required and tested to work. Think of it like the bundled mongodb but a little stricter.
If my system npm is 3.10.9 and meteor npm is 3.10.9, then it doesn’t matter which one I use, no?
Even if my system npm is a higher version than Meteor’s, how is npm install --save whatever going to behave differently between the two versions? Is a package installation not just a package installation at the end of the day?
The node binary shouldn’t even come into play here, since obviously running meteor will make it use its own internal version of node, correct?