I am trying to build a Meteor app using meteor build --directory ../dist. Everything seems to build fine, but when I follow the instructions provided in the generated README file I get an error saying the server/main.js file can't load. When I looked, I saw that the main.js file is not there.
Is there something I need to do before I build to ensure the file exists after build?
I'm having a very difficult time trying to build the Meteor app for a production serve, and I can't seem to find any clear instructions. The Meteor doc instructions are very vague in regard to build.
I can see how the README can be confusing if not followed as intended.
The first command line states:
$ (cd programs/server && npm install)
Note the parentheses.
Those cause the command to run in a subshell, which means that your shell will remain in the same directory after the command execution is done.
However, if you only execute the inner commands, you will end up in the programs/server directory and experience what you describe.
In any case, $ node main.js should be run from the bundle's root directory.
Related
I am trying to use Visual Studio Code as an alternative to Webstorm to edit and debug a toy Meteor app. After installing the MeteorHelper extension which is announced as provided "Meteor CLI integration into VSCode" and try to run any Meteor command I get the error msg:
"X is not a meteor project directory, check your workspace definition".
I don't know whether the problem is the LOCATION of my directory X, or its CONTENT (something is missing?). I changed the meteorhelper.relativeProjectPath string in the settings.json file to various possible values to no avail.
Has anyone out there tried to use VSCode to edit and debug a Meteor app and got that error?
A Meteor project directory is what gets created when using the command:
meteor create my-app
This command creates a folder that contains your Meteor applications' code. Typically, the directory structure looks something like this:
my-app/
.meteor/
client/
imports/
server/
package.json
The error you're describing would be encountered while attempting to run a project-specific meteor command from outside of a Meteor project. In the above example, I would access the project directory by first entering
cd my-app
on the command line.
I'm trying to run the Polymer Docs locally, but I get an error when trying to serve the app with grunt:
Running "appengine:run:frontend" (appengine) task
executing: dev_appserver.py --port=3000 --host=0.0.0.0 .
Fatal error: spawn dev_appserver.py ENOENT
(Full output)
The only relevant info I could find was this on the polymer-dev forum, but in that case the issue was using the incorrect Google App Engine SDK. I am using the Python SDK and I'm running Python 2.7.9.
EDIT: If you're finding this now, it's much easier to avoid this issue and use Gulp instead, basing it off of the Polymer Starter Kit gulpfile.
I was having the same troubles on Ubuntu 14.04. The solution for me was to add the absolute path to the Google App Engine Python SDK directory to my $PATH environment variable.
Edit shell startup script (I'm assuming you're using bash):
vim ~/.bashrc
Add the absolute path to Google App Engine directory:
PATH="$PATH:/absolute/path/to/google_app_engine"
Save and close file.
Remember that the changes won't take effect until the next time your shell starts up, so close and re-open your terminal now.
If that doesn't help, keep in mind that the ENOENT error generally means that a script is trying to access a file or directory that doesn't exist. So, for some reason, the path that Grunt is using to access the Google App Engine is incorrect.
I am working with a community-developed OpenShift cartridge for nginx. The cartridge's build script (without any modifications) works well; it starts the nginx server with the configuration file that I provide it. However, I am trying to modify the build script so that it first changes directory into my OpenShift repository, runs npm install and then grunt build to build an Angular application that I have created.
When I do this, I continuously get the error EACCES, mkdir '/var/lib/openshift/xxxxxxxxxx/.npm' when the script gets to npm install. Some OpenShift forum posts have attempted to solve the issue, but it appears as though a different solution is required (at least in my case).
Thus, I am interested in whether or not it is possible to use npm in this way, or if I need to create a cartridge that does all of this myself.
Since we do not typically have the access required to create ~/.npm, we have to find ways of moving the npm cache (normally ~/.npm) and the npm user configuration (normally ~/.npmrc) to accessible folders to get things going. The following information comes partially from a bug report that I submitted to Redhat on this matter.
We must begin by creating an environmental variable to control the location of .npmrc. I created a file (with shell access to my application) called .env in $OPENSHIFT_DATA_DIR. Within this file, I have placed:
export NPM_CONFIG_USERCONFIG=$OPENSHIFT_HOMEDIR/app-root/build-dependencies/.npmrc
This moves the .npmrc directory to a place where we have the privileges to read/write. Naturally, I have to also create the directory .npmrc in $OPENSHIFT_HOMEDIR/app-root/build-dependencies/. Then, in my pre-start webhook/early in my build script, I have placed:
touch $OPENSHIFT_DATA_DIR/.env
This ensures that the environmental variable that configures the location of .npmrc will be accessible each time we deploy/build. Now we can move the location of the npm cache. Start by running touch on the .env file manually, and create the .npm directory in $OPENSHIFT_HOMEDIR/app-root/build-dependencies/. Run the following to complete the reconfiguration:
npm config set cache $OPENSHIFT_HOMEDIR/app-root/build-dependencies/.npm
NPM should now be accessible each time we deploy, even if we are not using the NodeJS cartridge. The above directory choices may be changed as desired.
You do not have write access to the ~/.npm directory in your gear. You might try reviewing how the native node.js cartridge is setup (https://github.com/openshift/origin-server/tree/master/cartridges/openshift-origin-cartridge-nodejs) and see if you can apply it to your custom cartridge.
My meteor application works locally. When I bundle it (using meteor bundle myapp.tgz), upload it on my server and launch it, I have the following error upon opening the page on Chrome console:
Uncaught SyntaxError: Unexpected token <
On Firefox console:
SyntaxError: syntax error
[Break On This Error]
<!DOCTYPE html>
In order to try to find the origin of the error, I used an old bundle that was working. I can see the problem is that the files in static_cachable are not found.
Meteor is still trying to use the files from the old bundle.
If I rename the new bundled files in static_cachable to the old name then It works.
I checked in all files contained by the root of the bundle folder and references are correct (they are pointing to the new names).
It there some cache somewhere that keep the reference to the old static_caches files ?
To avoid the error, one has to restart Meteor after deployement :
rm -rf bundle
tar -zxf myapp.tar.gz
cd bundle/server/node_modules/
rm -r fibers
npm install fibers#1.0.0
export PORT=32632
export MONGO_URL=mongodb://meteor:**#localhost:18700/moviegrid
export ROOT_URL='mydomain.com'
nohup node bundle/main.js &
Look at the javascript console when you load your app locally and check if there is no error. If there is some, correct them before bundling/deploy.
This may not be your problem but according to http://docs.meteor.com/#deploying:
For now, bundles will only run on the platform that the bundle was created on. To run on a different platform, you'll need to rebuild the native packages included in the bundle. To do that, make sure you have npm available, and run the following:
$ cd bundle/server/node_modules
$ rm -r fibers
$ npm install fibers#1.0.0
Consider installing meteor on your server, cloning your app directory and using meteor run inside the directory to see if the app runs in development on the server.
If it successfully launches in development then bundle it on the server and use those files. Or just run with meteor --production
I posted this on the Kobold2d forums but haven't received any replies yet. I'm hoping the larger audience here at SO can help.
I'm trying to get our Kobold2d project working with our Hudson CI server. I'd like to have a script that executes the proper command line build instructions using xcodebuild, but I'm running into a problem with any Kobold2d project.
As a test I created a Orthogonal-Tilemap template project and built/ran it in the xcode 4.4.1 gui successfully. Building the projects individually from the command line the Kobold2D-Libraries.xcodeproj reports a successful build (though I have no idea where any products are stored), but the tilemap project fails with the message:
ld: file not found: <path>/Kobold2D/Kobold2D-2.0.3/BuildTest/build/Release-iphoneos/libkobold2d-ios.a
The only information I can find on this message talks about errors from building in the xcode gui, which is not the problem.
I also tried having xcodebuild build the workspace file but that failed with multiple dependency errors.
Has anyone found a way to successfully build Kobold2d projects from the command line?
Thanks!
Actually I use Hudson to automate Kobold2D builds. Here's the build script for Hudson.
I can see from your path that you changed Xcode's default build locations (Advanced, next to Derived Data in Preferences -> Locations). There's one setting (legacy) that doesn't work at all with Kobold2D, and should actually open a browser window explaining the issue should you have used that setting.
I think your setting is "relative to project" or something similar. Try changing the build location to Xcode default (Unique) and try again. You can use a custom location for derived data if you want to.
In any case, if the output location path of build products ends up being somewhere in the app project folder (in this case: BuildTest) then ld won't be able to find dependencies because they're not all in the same folder. If you do require this you could add a pre-link step that copies the .a files to the correct location. But it's best to avoid this because it'll be prone to breaking.
My script includes
xcodebuild -workspace Bulge.xcworkspace -scheme Bulge-iOS -sdk ${sdk} archive || die "Archive failed"