usage . guide github source . issues

flow file format

The flow file format is based on JSON, which should be familiar. The difference is that the format is parsed very loosely, allowing clarity and simplicity over inane JSON errors, while still supporting concise error reporting when errors are found in the project.

The following convention is used below :

Root nodes

Root nodes are in the parent object.
There are three reserved nodes.

flow

The flow node is your direct route to the flow tool config from a project file, to override and augment flow itself, as needed.

project

This is your project root node, where the majority of your flow is described.

if

This is a conditional project node. It mirrors some features of the project node, but wraps the nodes inside of conditions, allowing expressive control over the flow based on defines.

Custom root nodes

Aside from the three nodes above, the entirety of the flow file belongs to you, and the flow files in your dependency tree (more on this later).

What the project uses these nodes for is entirely up to the project, and flow will simply maintain the nodes and pass them to hooks, file templates and so on.

Project defines

When defined (shown later), these can be used in haxe code :

#if desktop
  desktop_code();
#else
  other_code();
#end

and in the conditional project nodes :

if: {
    desktop: {
        files: { desktop_config:'config/desktop.json => config.json' }
    }
}

Built in defines

For more info see the build.defines node

Conditional project nodes

inside the if node in the root, currently following nodes can be used :

The conditional nodes rely soley on the defines.

condition resolution

The conditional system allows you to use defines defined later. This means that all defines will be resolved (and all conditions that define new defines) before hand, so you can safely use one define to include new defines, and then use those defines. This can help simplify complex define expressions. For example :

if : {
    "mac || windows || linux || android || ios" : {
      build: {
        defines : ['is_native']
      }
    },
    "is_native && arch-32" : {
        ...
    }
}

Instead of using the entire long expression each time, a single shorthand can be defined, and relied upon to be resolved.

conditional statements

The conditions node supports the following operands

This means that you can use expressions to define exclusion/inclusion. Take note that due to the syntax, conditional statements with operands must be inside of quotes, single or double.

if: {
    'desktop && web': {
        ..
    },
    'mac && arch-32 && !static_link': {
        ..
    }
}

A flow file

Each of the links below take you to the relevant node on this page.
Take note that a lot of this is not required as the defaults will fill in the gaps.


{

  project : {
    name : 'empty',
    version : '1.0.0',
    author : 'luxeengine',

    app : {
      name : 'luxe_empty',
      package : 'org.snowkit.empty'
      output : 'bin/'
      main : 'Game',

        web : {
            libs : { ... }
        },

        mobile : {
            ..
            ios : { ... },
            android : { ... }
        }
    },

    build : {
      flags : ['-v', '--macro keep(example)'],
      defines : ['no_sfx', 'no_music'],
      dependencies : {
        example : '*'
      }
    },

    files : {
      config : { 
          path: 'config.template.json => config.json', 
          template:'project' 
      },
      data : 'data/ => assets/'
    }

  },

  if : {
    ...
  }

}

project properties

{
    project: {
        name: 'hello',
        version: '1.0.0-beta.1+2345',
        author: 'snowkit.org'
    }
}

project nodes


app

The app node controls build configurations specific to the binary/app output of a flow, if any.

app nodes

app.web properties

app.mobile properties

app.mobile.ios properties

app.mobile.android properties

build

The build node controls build specific configurations and files.

files

 

copying

templating