• If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Get control of your email attachments. Connect all your Gmail accounts and in less than 2 minutes, Dokkio will automatically organize your file attachments. You can also connect Dokkio to Drive, Dropbox, and Slack. Sign up for free.

View
 

BuildTools-Reference sc-server

Page history last edited by Ido Ran 9 years, 7 months ago

Usage

 

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]

 

Synopsis

 

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).

 

Options

 

-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.

 

Detailed Discussion

 

Provide any detailed documentation beyond  the synopsis above.  Any additional sections go here.

 

Setting up a proxy

 

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

 

History

 

Added in SproutCore 1.0.

 

 

 

 

Comments (0)

You don't have permission to comment on this page.