TIBET

Loading

Wins

Explicit control over package configuration and load conditions.
Single-page optimized with live patching without flushing data.
No module boilerplate in source code. No cyclic dependencies.
Fully-integrated metadata shared across app, tools, and CLI.
Full reflection data; all types, methods, attributes know load path.

Concepts

TIBET applications launch and load via the TIBET Loader, a powerful, configuration-driven resource loader capable of loading components from the file system (including Electron), or any HTTP-compliant server, including HTTP-aware DBMS's like CouchDB.

TIBET loading occurs in a sequence which allows you to integrate login-triggered loading, visualize load progress, pause after load, track load paths, and much more.

The TIBET Loader reads and processes package definitions to load resources. This approach allows you to define resource packages explicitly and apply conditions to each resource. Resources can load conditionally based on browser, user language, user role, etc. and do so during application launch or dynamically at runtime. You are in control.

Cookbook

Below are a few common things you may want to try out:

Show The Boot Log On Launch

Set boot.show_log to true:

http://127.0.0.1:1407#?boot.show_log

TIBET boot.show_log=true — #boot.show_log

By default the boot log will display messages output at the TP.SYSTEM level, a level reserved for system messages from TIBET.

Log At A Detailed Level During Boot

Set boot.level to a specific value from the list:

TP.ALL = 'ALL';
TP.TRACE = 'TRACE';
TP.DEBUG = 'DEBUG';
TP.INFO = 'INFO';
TP.WARN = 'WARN';
TP.ERROR = 'ERROR';
TP.SEVERE = 'SEVERE';
TP.FATAL = 'FATAL';
TP.SYSTEM = 'SYSTEM';
TP.OFF = 'OFF';

Note that you can use uppercase or lowercase level names:

http://127.0.0.1:1407#?boot.level=trace

When logging at TP.TRACE level the boot log will show you each file and inline script it loads, in order.

Log To The Browser Console

Set boot.console_log to true, or use it on the URL:

http://127.0.0.1:1407#?boot.console_log

TIBET boot.console_log=true — #boot.console_log&boot.level=trace

Console-directed logging can be extremely useful if you've modified the boot screens or made other changes to the default TIBET startup infrastructure.

Pause After Loading/Before Starting

Set boot.pause to true, or use it on the URL:

http://127.0.0.1:1407#?boot.pause

Boot with your debugger closed so you don't wait too long, then open it, set your breakpoints, get yourself set, and then yes, just click the play/pause button :).

Disable URL Argument Parsing

Set boot.nourlargs to true via tibet config or TP.sys.launch:

Via tibet config on the command line:

$ tibet config boot.nourlargs=true

Via TP.sys.launch in your index.html file:

...
<body onload="init()">
...
<script src="./node_modules/tibet/lib/src/tibet_loader.min.js"></script>
<script>
//<![CDATA[
function init() {
    TP.boot.launch({ boot: { nourlargs: true }});
}
//]]>
</script>
...
</body>
...

Load Unminified Code

Set boot.minified to false (with a development profile):

http://127.0.0.1:1407#?boot.minified=false&boot.profile=development

Reflect on Load Path

Query any TIBET type, method, etc. via the TP.objectGetLoadPath primitive:

TP.objectGetLoadPath(TP.core.Hash);

"~lib_src/tibet/kernel/TIBETCollections.js"

Loader Activation

TIBET applications load in response to invoking the TP.boot.launch method provided by the tibet_loader.js boot script (often in minified form).

For example, here's the relevant portion of the default index.html file:

...
<body onload="init()">
...
<script src="./node_modules/tibet/lib/src/tibet_loader.min.js"></script>
<script>
//<![CDATA[
function init() {
    TP.boot.launch();
}
//]]>
</script>
...
</body>
...

index.html (script portions)

Each of TIBET's default application templates provides an index.html file containing logic similar to what you see here. You include the tibet_loader.js script or a minified version of it and trigger TP.boot.launch once the page has loaded.

Load State

Once the TP.boot.launch sequence is triggered TIBET will begin loading resources. TIBET library resources load during phase one, your application resources load during phase two. During this process TIBET sets variables to track load status:

TP.sys.hasKernel();
TP.sys.hasLoaded();
TP.sys.hasInitialized();
TP.sys.hasStarted();

The TP.sys.hasKernel setting is defined by the last file of the kernel package, TIBETFinalization.js. This flag lets certain aspects of the system switch from "boot primitives" to "kernel primitives" which have more error handling.

The hasLoaded, hasInitialized and hasStarted flags let you know that TIBET has finished loading all resources, that it has initialized all types with an initialize method, and that it has triggered and completed the application startup sequence.

Startup Sequence

Once the system has loaded a sequence of methods and signals are invoked which provide you with multiple hook points into system activation. The rough sequence is outlined in the list below which takes things from start to finish:

TP.boot.launch()        // Trigger the loader to begin running.

TP.sys.hasKernel(true); // End of `TIBETFinalization.js` load.
TP.sys.hasLoaded(true); // End of all resources loading.

TP.boot.main()          // Invoked after all resources are loaded.
TP.boot.$activate()     // Installs onbeforeunload and similar hooks.
TP.sys.activate()       // Triggers application startup sequence.

//  Hookable signals prior to type and core initialization.
TP.signal('TP.sys', 'AppWillInitialize');
TP.signal('TP.sys', 'AppInitialize');

Type Initialization // Invokes `initialize` on implementing types.
Core Initialization // Series of initialization functions.
    'Initializing root canvas...'
    'Initializing type proxies...'
    'Initializing namespace support...'
    'Initializing default locale...'

TP.sys.hasInitialized(true);

//  Hookable signal for post-initialization processing. This is
//  a good place for things like registering strings for locales
//  etc. so they're available prior to UI loading.
TP.signal('TP.sys', 'AppDidInitialize');

TP.sys.loadUIRoot();    // Begins the UI loading/rendering cycle.

//  Hookable signals prior to application start invocation...
//  but after the UI has been loaded so initial screen DOM is
//  accessible.
TP.signal('TP.sys', 'AppWillStart');
TP.signal('TP.sys', 'AppStart');

//  Default handler for AppStart triggers...
TP.sys.getApplication().handleAppStart()

//  Normally not overridden, better to use signal handlers or
//  finalizeGUI.
TP.sys.getApplication().start(aSignal);

//  Override this as needed, but invoke TP.boot.showUIRoot()
//  when done or better yet `return this.callNextMethod()` :).
TP.sys.getApplication().finalizeGUI();

//  Hookable signal for post-startup processing. App is running.
TP.signal('TP.sys', 'AppDidStart');

Loader Framing

Like most web applications, TIBET applications start out from index.html. The TIBET difference is that you rarely edit this file since it defines framing to isolate code and data for single-page applications and reduce reload overhead.

The `index.html` file

Here's the relevant UI framing from the default index.html file:

...
<body onload="init()">
...
<iframe id="UIROOT" frameborder="0"
    src="./TIBET-INF/boot/xhtml/blank.xhtml"></iframe>
<iframe id="UIBOOT" frameborder="0"
    src="./TIBET-INF/boot/xhtml/UIBOOT.xhtml"></iframe>
...
</body>
...

index.html (ui framing)

Here we can see TIBET's standard UIROOT and UIBOOT iframe elements.

During loading your application typically displays content in the UIBOOT <iframe> which includes a variety of built-in boot progress displays. Once your application code has loaded your project's root page loads and the UIROOT <iframe> becomes active.

The Code Frame

We mentioned UIBOOT and UIROOT, the two <iframe> elements TIBET uses to manage the user interface during startup and application operation. There's one other frame (or more accurately Window) we haven't talked about: top.

In TIBET applications top is what we call "the code frame". During the loading phase your application code is loaded in top along with any shared data.

The content of the code frame (top) is never altered for UI purposes, your UI remains isolated in UIROOT, allowing you to completely reload the UI without impacting any shared code or data. Your code and data persist regardless of UI changes.

Loader Stages

The TIBET Loader actually operates by iterating through a sequence of stages, from a prelaunch stage which verifies the boot environment through the final stage where your application class has been triggered and is now running.

Here's the complete list of stages, in order, along with their general role:

{
    prelaunch: 'Verifying environment...',
    configuring: 'Reading configuration...',
    expanding: 'Processing boot manifest...',
    import_phase_one: 'Importing phase-one (static/library) components...',
    import_paused: 'Waiting to start phase-two import...',
    import_phase_two: 'Importing phase-two (dynamic/application) components...',
    paused: 'Proceed when ready.',
    activating: 'Activating application...',
    initializing: 'Initializing loaded components...',
    rendering: 'Rendering application UI...',
    liftoff: 'Application running.'
}

Prelaunch

The prelaunch stage verifies the current browser environment is supported. Verification involves a combination of feature detection and browser version checks. If the application cannot be run the launch is halted and an error message is displayed.

Configuring

TIBET is an integrated system and the Loader is no exception.

Once the environment has been verified the Loader loads and leverages TIBET Configuration data. The configuring stage handles loading configuration data, checking launch options, parsing url arguments, and ensuring the system is configured.

Expanding

Loader profiles are essentially file names which point to TIBET package files and configurations within those packages. During the expanding phase the Loader reads these files and expands them into a flat manifest suitable for loading.

Production profiles normally reference a flat manifest to minimize overhead.

Import (Phase One)

The TIBET library operates in terms of two logical packages: lib and app.

In large-scale application environments, particularly those where a number of applications are being developed and deployed, it's more efficient to have a common and cacheable shared library package and separate application packages.

TIBET recognizes the value of separating relatively static and potentially large library code from more dynamic and potentially smaller application-specific packages and uses import_phase_one to load static/shared library code.

While in this phase the configuration parameter boot.phaseone is true.

Import (Paused)

Perception is 9/10ths of reality and perceived performance is a key perception to manage for large applications which might otherwise seem slow to load.

One way of managing the perception of performance that's particularly useful for applications that require a login is to load static/shared library code early but only load application-specific code once a successful login has been confirmed.

The import_paused phase is a pause state specific to scenarios where the application wants to load shared code early, perhaps from the HTML5 cache, and only load the remaining code once a proper response from the server is received.

Import (Phase Two)

The import_phase_two stage is typically used to load application-specific resources which might change more frequently than the library code they rely on.

For example, as a TIBET customer your application code will be changing daily as you develop, but you may only update your TIBET library weekly, or monthly, to get the latest stable release of library code.

While in this phase the configuration parameter boot.phase_two is true.

Paused

Once all application code has finished loading the Loader will check the boot.pause configuration flag. If that flag is set the load sequence will pause at this point to allow you to set breakpoints etc. before proceeding. That can be very useful in browsers where having the debugger open during loading can cause dramatically slower load times.

Click the default boot UI's "play/pause" icon to complete the startup sequence.

Activating

The activating phase configures onunload hooks to ensure the user is prompted before unloading all the code we just loaded, and then calls TP.sys.activate, the TIBET library's startup routine.

At this point control actually moves from the Loader into the TIBET library.

Initializing

TIBET is a heavily object-oriented library with hundreds of types. Before triggering your application class to start() all types with an initialize method have that method run so they can do any post-loading/pre-start initialization required.

Rendering

The rendering phase is responsible for getting your application's UI ready for use.

To render your application UI on startup TIBET leverages the values of two configuration variables: project.rootpage and project.homepage.

The Root Page

The first configuration setting, project.rootpage, defines the URL to load into UIROOT once all code has loaded. This value defaults to UIROOT.xhtml, a file whose content is simple, but indicative of perhaps TIBET's most striking difference from most libraries:

...
<body>
    <tibet:root/>
</body>
...

UIROOT.xhtml

Not much there, just a single custom tag: <tibet:root/>; what we call the "root tag". As we'll see there's a lot of power in that tag and the TIBET Tag System that supports it.

The Home Page

We mentioned there were two configuration variables driving your UI on startup. The second of those values, project.homepage, is used by <tibet:root/>.

The <tibet:root/> tag's role is to decide which home page to load and whether to load it with or without TIBET's browser-based IDE, the Lama™.

If lama.enabled is true the Lama will load and your home page will be rendered by the Lama, otherwise your home page loads directly into UIROOT. Note that the Lama itself might not be visible (by default it is hidden but can be triggered if lama.show_toggle is true). The Lama can also be shown immediately on launch by setting boot.show_ide to true.

By default project.homepage resolves to a standard file, home.xhtml, in your application's TIBET-INF/boot/xhtml directory.

If you're starting to suspect home.xhtml contains more custom tags you're right. The default version contains what we call the "app tag", a custom tag which represents your application in reusable, easy-to-reference markup.

...
<body>
    <demo:app/>
</body>
...

home.xhtml

The implication of organizing your application around an "app tag" is that all TIBET applications are inherently reusable and composable.

We can take our <demo:app/> tag and use it anywhere, not just as a standalone application but as a component in a larger-scale application.

Further, having an application tag implies that there's little reason to alter home.xhtml. That file isn't responsible for your application UI, your application tag is.

Liftoff

This is the final stage, which performs no processing but is simply a way of signifying to other system components that the application has started.

This phase is set by the TIBET library once the UI has fully loaded and the application has finished running its start() method. For more on the library startup sequence see the documentation for the TP.core.Application type.

Stopped

There's one other stage the loader can find itself in…which hopefully you'll avoid :)

stopped: 'Boot halted.'

The stopped stage is set when a fatal error occurs during booting.

There are two common ways a fatal error can occur. One is that the error is logged at the FATAL level, and the other is that boot.fatalistic is true and an error in a library phase (activating, initializing, rendering) is logged.

Loader Profiles

When the Loader starts it relies on configuration settings to help it determine what to load and how to load it. The most important of these Loader-centric configuration settings are the boot.profile and boot.config values.

boot.profile

The boot.profile setting tells the Loader which TIBET package file to read.

In the example below we're telling the Loader to boot the development profile:

http://127.0.0.1:1407/#?boot.profile=development

If you've read TIBET Configuration you should recognize the URL above as one whose fragment (hash) contains URL-based configuration parameters read by the Loader.

Loader boot.profile values must resolve to a full path but TIBET provides a lot of defaulting to keep things simple. As a result most boot.profile values are simple file names without directory or extension information.

By default TIBET packages are found in a directory defined as ~app_cfg, which defaults to the TIBET-INF/cfg directory in your application's root directory. Load packages must be XML so we can use a .xml extension to arrive at ~app_cfg/development.xml.

This value defaults to main and hence ~app_cfg/main.xml.

boot.config

Along with the boot.profile the Loader needs a value for boot.config which defines the config ID in the package to load, literally a config element ID.

Your boot.config can default based on content in the package or specified directly or indirectly in your TIBET configuration.

You can define boot.config explicitly using a second boot parameter (or in your tibet.json file for persistent settings):

http://127.0.0.1:1407/#?boot.profile=development&boot.config=developer

For simplicity you can also specify the boot.config value as part of your boot.profile by adding a '@' as follows:

http://127.0.0.1:1407/#?boot.profile=development@developer

This latter form is far more common since it's a bit cleaner and easier to use.

The boot.config value defaults to the value of the default attribute on the boot.profile document's root <package/> element.

Loader Packages

Package Files

A package file is an XML file containing at least one root <package/> tag and one child <config/> tag used to define load scripts, resources, and properties.

Here's the default package used by most TIBET applications:

<?xml version="1.0"?>
<package xmlns="http://www.technicalpursuit.com/1999/tibet"
    id="demo" default="base" basedir="~app_cfg">

<config id="base">
    <package src="tibet.xml" config="base"/>
    <package src="{{appname}}.xml" config="base"/>
</config>

<config id="full">
    <package src="tibet.xml" config="full"/>
    <package src="{{appname}}.xml" config="full"/>
</config>

<config id="developer">
    <package src="tibet.xml" config="developer"/>
    <package src="{{appname}}.xml" config="developer"/>
</config>

<config id="contributor">
    <package src="tibet.xml" config="contributor"/>
    <package src="{{appname}}.xml" config="developer"/>
</config>

<config id="test">
    <config ref="developer"/>
    <package src="{{appname}}.xml" config="tests"/>
</config>

</package>

~app_cfg/main.xml

As you can see from this package file the lib vs. app pattern is very clear. The tibet.xml packages provide configurations of library code while the {{appname}}.xml packages provide configurations of your application code.

`<package/>` Tags

A root <package/> tag provides information about the package such as the package name, the default config ID to load in the absence of a boot.config value, and the base directory from which to compute any relative paths.

<package xmlns="http://www.technicalpursuit.com/1999/tibet"
    id="demo" default="base" basedir="~app_cfg">

Looking back at the main.xml package we just listed the package name is demo and the default config ID is base. The basedir for path computation is ~app_cfg.

As shown in the main package, <package/> tags can also be used within a <config/> tag to point to an external package. This allows you to create nested packages and easily reference external component configurations.

The following entry refers to the {{appname}}.xml package's tests config:

<package src="{{appname}}.xml" config="tests"/>

`<config/>` Tags

A TIBET <config/> tag defines a specific set of resources to load and any properties which should be defined during the configuring stage of the load process.

The Loader always works from the boot.config referenced <config/> tag down, recursively expanding all its contained <config/> and <package/> components until it has a flattened list of load resources, properties, and instructions. Circular references are discarded and duplicates are removed so you get a single, consistently ordered list.

Let's look at a few examples pulled from the default {{appname}}.xml package:

...
<config id="base" if="boot.phase_two">
    <config ref="app_img"/>
</config>

<config id="app_img">
    <script src="~app_src/APP.demo.js" />
    <script src="~app_src/APP.demo.Application.js" />
    <script src="~app_tags/APP.demo.app/APP.demo.app.js" />
</config>
...

The three <config/> tags in our sample provide a good look at typical usage.

The first <config/> tag has an id of base, which is the typical default for most packages. In the absence of other information you can assume this config will be the one loaded. Note that it loads during phase two (the app phase).

The second <config/> is actually nested inside our base config and has no id attribute. Instead it has a ref attribute which points to the third config tag, literally including it by reference. This approach is common since it makes it easy to compose large configurations from smaller modules.

The third <config/> is identified as app_img and contains three <script/> elements which reference source code residing in the application's source and tags directories (referenced here as ~app_src and ~app_tags).

`<script/>` Tags

Loader <script/> tags are similar to typical script tags with the exception that they are never processed in an HTML context. As a result they serve only as instructions for the Loader with respect to the resource to load.

<script src="~app_src/APP.demo.js" />

Most script tag entries point directly to a source file via their src attribute, but the Loader also supports inline source in a script tag. Note the use of a CDATA block here; these are XML files, not HTML files, so CDATA blocks avoid problems with embedded entities:

<script>
<![CDATA[
    TP.extern.JsDiff = JsDiff;
]]>
</script>

You can leverage inline script to handle potentially complex loading scenarios. In the following example we put a CommonJS module wrapper around an external module used by the TIBET test harness to load it properly:

<config id="gui">
    <script>
    <![CDATA[
        if (TP.sys.cfg('boot.context') !== 'phantomjs') {
        (function() {
    ]]>
    </script>
    <config ref="syn"/>
    <script>
    <![CDATA[
        }());
        }
    ]]>
    </script>
    <script src="automation/TPGUIDriver.js" />
</config>

`<property/>` Tags

The <property/> tag gives you a way of setting TIBET Configuration values specific to a <config/>. A common place for this is in developer profiles where you may want to set more verbose logging or debugging flags.

Here's a canonical <config/> named properties which loads during phase one and which alters several flags useful for development:

<config id="properties" if="boot.phaseone">
    <property id="tibet.lama" value="true"/>
    <property id="debug.use_debugger" value="true"/>
    <property id="log.bootcfg" value="true"/>
    <property id="log.bootenv" value="true"/>
    <property id="log.level" value="DEBUG"/>
    <property id="log.stack" value="true"/>
</config>

The Loader processes property tags as part of the loading process so its best to configure them to be run in phase one and as the first part of a larger config:

<config id="base">
    <config ref="properties"/>
    <package src="standard.xml" config="base"/>
</config>

`<resource/>` Tags

A <resource/> tag lets you specify templates, style sheets, or other resources which might otherwise be missed by the TIBET packaging logic.

Under normal circumstances a templated tag will assume a matching xhtml and css file but in some cases you may find it necessary to tell the system about additional resources. When more control is needed use a resource tag.

You can reference a block of resources using a directory reference rather than an explicit file name. For example, here's the standard resources target from a typical application configuration file:

<config id="resources">
    <!-- put non-bundle resource entries here -->
    <resource href="~app/styles"/>
</config>

To refer to specific resources simply use the href attribute of the resource tag to point to the target asset.

`<echo/>` Tags

An <echo/> tag gives you a simple way to inject your own messages into the log:

<echo message="hi there"/>

You can use the level attribute to set a TIBET log level for the message.

Package Examples

For more examples of usage see the package files in an application's TIBET-INF/cfg directory or in the TIBET library's lib/cfg directory.

Virtual Paths

We've seen/used configuration values beginning with a ~ (tilde) in a few places. These references are what TIBET calls "virtual URIs", paths whose concrete value is resolved at runtime by looking at the launch root and other startup data.

A virtual path of ~app_src may resolve to file:/c://some_source_directory on Windows, to file:///some_src_dir on Unix, and https://myhost.com/src when the application launches via https. That's the value of a virtual URI, it gives you a way to point to a file without a hard-coded path you may have to update later.

To see the actual location referenced by a virtual path replace the ~ with path. on the tibet config command line or in the TP.sys.cfg() call. It may be necessary to recursively perform this operation to get full resolution:

$ tibet config path.lib_boot
{app_directory}/node_modules/tibet/TIBET-INF/boot

Conditional Loading

For every tag it comes across the Loader checks for if and unless attributes. If the tag has either one, or both, the Loader will check the configuration value referenced to determine whether the tag is relevant.

For if tags the value must resolve to true for the tag to be used.

For unless tags the value must resolve to false for the tag to be used.

Tags containing both conditions must obviously pass both tests.

Value checking for if and unless considers the results of the TP.sys.isUA call (for browser checks), the TP.sys.env call (for "environment" settings), and the TP.sys.cfg call (for configuration settings).

A common test is a phase check to ensure a certain config or script is only loaded during a particular phase:

<config id="base" if="boot.phase_two">
    <config ref="app_img"/>
</config>

Another common case is checking for boot.unminified to constrain loading:

<script src="~lib_deps/bluebird-tpi.min.js"
    unless="boot.unminified" no-minify="true" no-lint="true"/>

Note the no-minify attribute used by tibet rollup and the no-lint attribute used by the tibet lint command here; both are good examples of leveraging the Loader's package descriptions for more than loading.

Loader Screens

The TIBET Loader doesn't just load code, it also provides a variety of ways to get visual feedback during the boot process. For example, on startup TIBET will display a default load screen and interactive progress bar during loading:

The Boot Page

What you see while you boot is controlled by a variety of factors but the most important is simply the file which is placed in the UIBOOT frame.

The default UIBOOT page is TIBET-INF/boot/xhtml/UIBOOT.xhtml. This value is set in your project's index.html file as you may recall. Changing it to point to any other page is a simple way to change your application's boot screen.

Boot Page CSS

Rather than altering the page you could simply manipulate the CSS which affects it. Your project's app.css file, typically found in styles/app.css, is loaded in your UIBOOT.xhtml, UIROOT.xhtml, and home.xhtml files for this reason.

The UIBOOT.xhtml file contains a number of elements whose id values begin with BOOT- giving you an easy handle to most of them.

For example, you can turn off display of everything but the standard Loader progress bar using the following CSS in your project's app.css file:

#BOOT-IMAGE, #BOOT-SPLASH, #BOOT-HEAD, #BOOT-SUBHEAD {
    display: none;
}

Obviously you can use this approach to change images, alter colors, fonts, etc. to meet the needs of your project.

Missing Boot UI

The boot parameters which define IDs for UI elements help the loader find those elements in the UIBOOT frame. If the elements aren't found the Loader simply continues. This allows the Loader to run regardless of how you decide to manipulate the UI page.

As a test you can "turn off" a lot of the boot UI interactions by altering the ID the Loader is looking for, setting it to something that can't be found.

http://127.0.0.1:1407#?boot.uiboot=MISSING

In this latter case you might want to combine that flag with some CSS alterations so your users don't see the prelaunch phase display. The key point is you have complete control over the boot UI.

Loader Configuration

The Loader both installs and leverages the TIBET Configuration subsystem. During startup the Loader relies heavily on configuration values with a boot prefix.

Here's a current list of boot-prefixed configuration values:

{
    "boot.console_log": false,
    "boot.context": "nodejs",
    "boot.defer": true,
    "boot.delta_threshold": 50,
    "boot.error_max": 20,
    "boot.fatalistic": false,
    "boot.karma_offset": "../../../../..",
    "boot.karma_root": "/base",
    "boot.level": "INFO",
    "boot.libcomp": "script",
    "boot.loader_offset": "../../..",
    "boot.moz_xpcom": false,
    "boot.no_tibet_file": false,
    "boot.no_url_args": false,
    "boot.parallel": false,
    "boot.pause": false,
    "boot.pause_on_error": false,
    "boot.phantom_offset": "../../..",
    "boot.reporter": "console",
    "boot.rootcomp": "tibet_dir",
    "boot.show_ide": false,
    "boot.show_log": false,
    "boot.stop_onerror": false,
    "boot.supported_browsers": {"ie":[{"major":11}],"chrome":[{"major":39}],"firefox":[{"major":34}],"safari":[{"major":7}]},
    "boot.supported_contexts": ["browser","electron","phantomjs"],
    "boot.teamtibet": false,
    "boot.tibet_dir": "node_modules",
    "boot.tibet_file": "tibet.json",
    "boot.tibet_inf": "TIBET-INF",
    "boot.tibet_lib": "tibet",
    "boot.tibet_loader": "tibet_loader",
    "boot.tibet_pub": "public",
    "boot.toggle_key": "TP.sig.DOM_Alt_Up_Up",
    "boot.two_phase": true,
    "boot.uiboot": "UIBOOT",
    "boot.uicommand": "BOOT-COMMAND",
    "boot.uiconsole": "BOOT-CONSOLE",
    "boot.uihead": "BOOT-HEAD",
    "boot.uiimage": "BOOT-IMAGE",
    "boot.uiinput": "BOOT-INPUT",
    "boot.uilog": "BOOT-LOG",
    "boot.uipercent": "BOOT-PERCENT",
    "boot.uiprogress": "BOOT-PROGRESS",
    "boot.uisplash": "BOOT-SPLASH",
    "boot.uisubhead": "BOOT-SUBHEAD",
    "boot.unminified": false,
    "boot.unminified_lib": false,
    "boot.unresourced": false,
    "boot.unsupported": false,
    "boot.use_login": false
}

Documentation for the individual flags is currently sparse, but you can get a decent idea of how each flag is used by looking at the content of ~lib_boot/tibet_cfg.js.

Loader Integration

One final thing to be aware of is that the package files used by the Loader are also used by the TIBET CLI and the TIBET Lama.

For example, there's a <config/> used to build the Loader itself which is used by the tibet rollup command we use within the library:

<config id="loader">
    <script src="~lib_src/tibet/kernel/copyright.js" no-minify="true"/>
    <script src="~lib_src/tibet/boot/tibet_pre.js" />
    <script src="~lib_src/tibet/boot/tibet_cfg.js" />
    <script src="~lib_src/tibet/boot/tibet_base.js" />
    <script src="~lib_src/tibet/boot/tibet_post.js" />
</config>

Examples of commands which use package file information include lint, test, package, resources, and rollup. These commands are able to focus on the specific files your application uses rather than scanning or relying on ignore patterns.

Attribute values are also relevant. For example, the rollup command makes use of the no-minify attribute on the copyright.js entry to ensure that the copyright comment isn't stripped out of the rolled up version(s) of the tibet_loader.js script.

By leveraging an external manifest-style package and config format all of TIBET can share Loader metadata and augment it as needed.

TIBET's runtime client library can tell you which file loaded every single type, method, and attribute in the system thanks to Loader integration. Using this information the Lama can edit a method, template, or other component in context.

These are just a few examples of the value of having consistent, easily managed descriptions of your application resources and configurations.

Code

The TIBET loader code is found in ~lib/src/tibet/boot. Additional components expected by the Loader are found in projects under the TIBET-INF directory.