-
Notifications
You must be signed in to change notification settings - Fork 7
Abbot features
Nicolas Badia edited this page Jan 23, 2015
·
48 revisions
This page keeps track of Abbot features (and other features) implemented in the build-tools.
- configuration scheme (inherited part of the nodified SC environment)
- combined files (implemented using a few array controllers per framework)
- sc_super replacement (inherited part of the nodified SC environment)
- sass parsing
- sc_static (should work, adding api changes which allow cross framework resource lookup)
- compass parsing (the part the ace theme uses)
- watchers: the buildtools do no longer have to be restarted whenever files are added or deleted. Changes are picked up automatically and cached. The changes also automatically retrigger sorting (tested)
- @if debug code selection
- fallback to global frameworks folder in case of a framework not being in the projects frameworks folder (was already in, but didn't work until a fix in sproutcore:team/mauritslamers/sproutnode)
- installer for frameworks: uses git to checkout a given repository and install it either in the project frameworks folder (default) or in the build-tools frameworks folder for global access. The build-tools now use this to install sproutcore after the build-tools installation itself has been completed.
- saving (building)
- For a build only the resources that are actually used are included
- minification, can be applied on combined files, and non-combined files.
- content hashing (unique build number based on content): added a computed property which calculates the SHA1 hash of the processed contents of a file or a framework as a whole
- proxy support, improving on abbot: simultaneous proxy requests, and a catch all proxy, which proxies every url which does not fit any url in the dev server.
- testing app support (targets.json and wrapping of actual tests in html)
- Module support (thanks to Nicolas Badia)
- html5 content manifest (Nicolas Badia)
- Combining of WrapperFrameworks (such as SproutCore itself)
- full @2x support
- different apps for different languages
- slicing: currently data urls only, and no magenta background to show errors. The code to add the magenta background is already present in the slicing, but commented out, because it caused a magenta edge around all pictures where Abbot didn't for the same app (todos_three)
- Windows support (32bit, works under WinXP), no x64 version yet of the slicing library (node-canvas). Please test the current version, and a volunteer to compile a 64 bit version of node-canvas would be very welcome!
- slicing (sprites)
- slicing (sprites)
- integrated doc viewer
- installation of themes similar to installation of frameworks
- post-build script (useful for integrated apps such as cordova and / or couchdb apps)
Note: The following is outdated on a few things, but kept around for the valuable bits it still contains of earlier discussions.
Stage 1:
- detection (and parsing) of configuration files.
We will need a replacement for the Buildfiles. JSON has been proposed, and would
work pretty straightforward, though the editing of a JSON file is not really
pleasant. A discussion is needed on what to configure exactly, but there are at
least the following items:
- Frameworks
- combineScripts + combineStylesheets
- minifyScripts + minifyStylesheets
- createSprite: should all images referred in the framework be packed as a sprite? if false, use data uris
- styleSheetProcessor: which stylesheet processor should be used
- combineOnSave + minifyOnSave: separate setting for production (can also be achieved by creating two sets of settings for one app)
- testsEnabled: include tests, and make test runner app available.
- watchForChanges: should the files of this framework be watched for changes?
- isModule + shouldPreload: should the framework be considered a module, and should it be packaged seperately?
- dependencies
- buildLanguage
- buildVersion
- Apps
- theme: which theme should be used?
- name: what is the name of the app
- detection of folders => result is an array with folders
Reason to do the detection ourselves is that it is hard to have the
following rules using the node-glob / minimatch syntax (see the gulp example above):
- In the project root, take only the apps, modules and frameworks folder
- In the apps folder, take all folders
- In every folder inside the apps folder, take all subfolders. Only two exceptions: "fixtures" should only be included in development mode, and "tests" should only be included when the configuration has tests enabled.
- For the modules folder steps 2 and 3 apply
- For the frameworks folder, only take the folders which are mentioned in the configuration, with the exception of sproutcore, which should override any installed sproutcore for this project
- Every folder in the frameworks folder that should be included can exist in
essentially two modes:
- a framework bundle: a collection of frameworks (sproutcore as an example). In this case the configuration tells what to include. Anything that can be included is either stored in a frameworks folder, or in a themes folder. This system can be recursive!
- a normal framework. Include everything.
Stage 2. Assembling app consists of the running of a set of tasks
- Scripts 1. Scripts need to be sorted, based on the following rules: a. lproj folder b. core.js c. bootstrap.js, d. everything alphabetically except for debug/test when not in debug mode, e. main.js Order can be changed through sc_require. 2. Scripts need to be parsed for static_url and sc_static references, which need to be replaced by a url. In garcon the images need to exist in the framework itself. In abbot the rules for where these images can be found are a bit blurry, as for example the desktop framework refers to an image inside a theme. 3. Scripts need to be parsed for sc_super(), which needs to be replaced by arguments.base.callee.apply(this,arguments). Because in ES5 and above arguments.base is removed, sc_super needs to be revisited (is this already the case in master?) 4. Depending on configuration: combining and/or minifying.
- Stylesheets 1. Stylesheets need to be prepended with the contents of the $theme.css file if found in the same folder 2. the theme.css file should be excluded from the list of files to be processed 3. Stylesheets need to be parsed for sc_static or static_url to be replaced by a url. In garcon the images need to exist in the framework itself. In abbot the rules for where these images can be found are a bit blurry, as for example the desktop framework refers to an image inside a theme. 4. Stylesheets need to be parsed by chance for slicing 5. Stylesheets needs to be processed by the configured style sheet processor (compass/sass/less) 6. Stylesheets need to be parsed again by chance to finalize some processes 7. Depending on configuration stylesheets are minified and combined
- Resources do not have to be parsed but should get a specific url
Stage 3. Serving or Saving The end product of the build tools is either a package that can be served by the development server or saved to disk for deployment.
- Serving: Serving is essentially a relative build, but has extra's: a. Test runner app: application included with SproutCore used to run the unit tests. This app needs per framework a file called targets.json which contains all filenames of the tests inside the framework. When a test is retrieved the server needs to wrap it in a HTML file in order for it to run.
- Saving: There are quite a few possible scenarios to be supported: a. relative builds: When deploying in environments like a CouchApp or Phonegap/Cordova, or simply an app on disk which doesn't need a network connection, the end result should be a build with relative paths. b. absolute builds: When deploying on a "normal" webserver, absolute paths are a vital ingredient to optimize browser caching. c. absolute builds with hashed paths: To further optimize browser caching, having a content hash in the path or filename is extremely useful. In addition it is useful to be able to define post-build tasks, especially in environments like PhoneGap.
There are additional wishes for the buildtools such as:
- Separate sproutcore versions in one project (very useful for porting)
- Being able to configure sproutcore differently for different applications. A possible scenario is a mobile and a desktop application in the same project, where the mobile app can / should have a different sproutcore configuration than the desktop app.