sc-server [target1 .. targetN] [--languages=LANG|-L] [--build=BUILD-NUMBER|-b] [--[no-]include-required|-r] [--project=PROJECT|-p] [--manifest=MANIFEST|-m] [--target=TARGET-PATH|-t] [--all|-a] [--[no-]symlink] [--mode=MODE|-M] [--clean] [--verbose] [--debug] [--help]
Builds one or more JavaScript bundles.
This tool is the primary entry point into the SproutCore build system to generate output suitable for deployment on your production servers. Most of the time, you can invoke this tool with the simple form:
sc-server app-name -r
This will build your app to your build location (usually ./tmp/build) along with any required bundles. This mode will auto-detect the installed languages in your application and build for all of them. If you have a previous build in that location, it will be updated without doing a clean build. Symlinks will be enabled in this mode if your build platform supports symlinks.
Most of the other options described here are mostly useful if you are using an automated build system and you need to specify options more exactly. Aside from using the build options here, you can also customize your build extensively by modifying the Buildfile included in your project. See the detailed discussion below for more information. Usually you will want to provide most of your customization through the Buildfile since that will be picked up by sc-server for use during development as well.
Note that if you have multiple applications defined in your project (say you are building a suite or have a desktop and mobile version), you can also omit the list of targets altogether. This will build every target in your project along with any required dependencies (unless you disable that behavior with --[no-]include-required).
| -a, --[no-]all | If you do not name any targets, normally all bundles will be built except those with the "autobuild" option set to false in their configs. Passing this option will build all targets, including those with autobuild turned off. |
| -L, --languages=en,fr... | Manually specifies the exact languages you want to build. This will effect all bundles, including dependencies. Normally the build system will autodetect the languages you have created. This option overrides that behavior. |
| -b, --build=NUMBER | Manually specifies the build number you want used for building. You can either pass a single build number, which will be used for all bundles, or you can pass build numbers of each bundle using the format "--build=sproutcore:1a23,contacts:3b42", etc. If you specify an "all" build number, the number will be used for bundles not explicitly named on the command line. Note that you can also name a build number for each bundle in your Buildfile. |
| -r, --[no-]include-required | Builds any dependent bundles with the targets you specifically named. For simple build and deployment systems, this is usually the best option, though if you have an automated build system you may prefer to build each target independently and therefore disable this option. |
| -p,--project=PROJECT | Manually specifies the path to the project you are building from. Normally sc-build expects your current working directory to be somewhere inside of the project you are building. You can invoke the tool from anywhere, however, and use this option instead to specify the project directory. |
| -m, --manifest=MANIFEST | Manually specifies the manifest file to use when building. A manifest file describes all of the build actions required to build this particular project. Normally a manifest is automatically generated as the first step of the build process, but you can override this by naming the manifest yourself. You may want to do this, for example, if you generate the manifest and then tweak it before building. |
| -t, --target=TARGET-PATH | Manually specifies the target directory to place build output. Normally this is derived from the project's build_root config (default ./tmp/build). You may want to use this if you are using an automated build system and you want all of your build output to go to a particular directory. |
| -d, --[no-]docs | Builds documentation for your bundle in addition to building the bundle itself. This uses the new sc-doc tool. |
| --[no-]symlink | Enables the use of symlinks. If you use symlinks, then places where you need duplicate copies of a resource may simply symlink back to an original source. This makes your built products smaller but it will not work when deployed on Windows machines and it makes it harder to strip out language directories. The default for this mode is to leave symlinking turned OFF, but you can enable it if final package size is important to you. |
| -M, --mode=MODE | Manually specify the build mode you want to use. Build modes swap in a different set of build options that may, for example, combine javascripts or not, minify or not, and so on. The default build mode for sc-build is "production", which is usually the mode that you want. |
| -c, --[no-]clean | Cleans the build output (by removing the build directory) before doing a build. The default behavior simply updates existing files that have changed, which is faster but it may at times leave old artifacts around (such as images you've since removed or renamed.) Before you do a build destined for production, it is a good idea to always do a clean build. |
| -v, --verbose | Enables the verbose log level. This is useful if you need to see exactly the steps performed during the build to ensure your options are working properly. |
| --debug |
Enables debug log level. This is useful if you are writing your own Buildfile or otherwise hacking the build tools |
| --port=number |
Switch the default port number. This allows you to run several instances of sc-server. |
In addition to the above options, the following deprecated options are supported for backwards compatibility:
| -e, --environment=MODE | Same as the new --mode option. This option name came originally from the build tools Rails heritage but it has been renamed to match the Buildfile build_mode option. |
| -l, --library=PROJECT | Same as the new --project option. "Libraries" were renamed "Projects" to match the terminology used in documentation. |
Provide any detailed documentation beyond the synopsis above. Any additional sections go here.
It is common to setup a proxy so that your Sproutcore application can make calls to a backend server.
The proxy configuration for sc-server is easy to use.
Let's say you have a JSON REST service called:
http://myinternalserver.com/foo/crud
And you are running sc-server locally for development. You would like your sproutcore application to be able to call http://myinternalserver.com:9090/foo/crud.
The problem is to avoid cross site scripting attacks, browsers do not let your client JavaScript to call foreign IPs, i.e., IPs other than the one it was launched from. You can't even call foreign ports on the same IP. (See Same Origin Policy in Wikipedia)
This is where sc-server can really help you.
Modify the Buildfile in your project directory. And, add the following statement to the file.
proxy '/foo', :to => 'myinternalserver.com:9090'
Now all requests will be forwarded to to the foo REST service on myinternalserver.com:9090.
Thus if you executed this in your Sproutcore application code:
SC.Request.postUrl('/foo/crud').header({
'Accept': 'application/json'
}).json()
.notify(this, this.didCreateTask, store, storeKey)
.send(store.readDataHash(storeKey));
This would map to this request:
POST /foo/crud HTTP/1.1
Content-Type: application/json
User-Agent: Safari Mobile
Host: 0.0.0.0:4020
Content-Length: 27
{"description":"getGeos", "isDone":true}
Which would then get proxied to (delegated-to/result-in) this:
POST /foo/crud HTTP/1.1
Content-Type: application/json
User-Agent: Safari Mobile
Host: myinternalserver.com:9090
Content-Length: 24
{"description":"getGeos", "isDone":true}
Now a common gotcha is if you try to do something like this:
proxy '/services', :to => 'myinternalserver.com:9090'
The above means that 0.0.0.0/services will map to myinternalserver.com:9090/services, not the root of the server.
Thus if the client calls this:
SC.Request.postUrl('/foo/crud').header({
'Accept': 'application/json'
}).json()
.notify(this, this.didCreateTask, store, storeKey)
.send(store.readDataHash(storeKey));
The sc-server will try to execute this request:
POST /services/foo/crud HTTP/1.1
Content-Type: application/json
User-Agent: Safari Mobile
Host: myinternalserver.com:9090
Content-Length: 24
{"description":"getGeos", "isDone":true}
Of course, your server does not actually handle this address. This is a common issue on the support group.
Another parameter you can set for proxy in your Buildfile is url. You can use it when your production environment is using URLRewrite and you don't have the same settings in your development environment.
For example let's say that you application will be deploy into myserver.com and will talk to backend service at myserver.com/db but the link on your development machine is localhost:4020/service
To handle that you add the following link to your Buildfile:
proxy '/db', :to => 'localhost:4020', :url => 'service'
Thus if the client calls this:
SC.Request.postUrl('/db/123').header({
'Accept': 'application/json'
}).json()
.notify(this, this.didCreateTask, store, storeKey)
.send(store.readDataHash(storeKey));
The sc-server will try to execute this request:
POST /service/123 HTTP/1.1
Content-Type: application/json
User-Agent: Safari Mobile
Host: myserver.com
Added in SproutCore 1.0.