crossbow-js / crossbow

Beyond NPM scripts

BEYOND NPM SCRIPTS

Unifying the use & configuration of plain functions, gulp-style streams, tasks in separate files,
shell/NPM scripts plus much more!

npm install -g crossbow

Get Started!

---

What's different?

We are NOT creating a whole new eco-system of plugins, rather we enable re-use and composition of your exiting tools! This is powered by a powerful task resolution system, an extremely reliable execution technique and an advanced recursive queueing system. At the same time we provide best-in-game error handling, features that are not possible in other tools and an all-round better developer experience.

Get started!

crossbow's Issues

should warn when file extension is not supported

Should allow top-level 'env' config for setting user flags across all child processes

options should allow single values

eg:

task:
  type1: 'somestring'
  type2: 'someptherstring'

must allow inline functions with task dep array

Use case:

cb.task('serve', ['build-all'], () => {
    bs.init({
        server: './',
        open: false
    });
    cb.watch(['*.html'], ['jade', bs.reload]); // NOT WORKING
    cb.watch(['*.html'], ['jade', () => bs.reload()]); // NOT WORKING
    cb.watch(['*.html'], ['jade', 'reload']); // WORKING
});

Should always log input file being used

should exec files directly when no export available

default reporter should not 'toString' on inline functions

support multiple configuration files

use same concept where the input to the right overrides that on the left.

This could be useful for overriding defaults in dev mode etc

pre-launch todo

todo items that are blocking launch

• Watchers need 'block' option - this is to avoid long-running processes from executing again before the previous run is complete. This is not always the desired behaviour, so needs implementing
  via a 'block' option on watchers
• Need to implement task-name flags, this is to allow easier combinations of series + parallel tasks.
  eg: Currently if you had 2 top-level tasks build-css and build-js - they both probably have sub-tasks that need to run in series, but the tasks themselves can run in parallel. This is currently implemented in the task-running stage, rather than the task-name stage

remove 'series' option from interactive run mode

task-name flags (for parallel groups)

for example, in the following case, child tasks of both build-js and build-css need to be run in series, but the two tasks themselves can run in parallel.

tasks:
  build-all:
    - build-js
    - build-css
  build-js:
    - lint
    - webpack
    - uglify
    - manifest
  build-css:
    - sass
    - cssmin

we want all child tasks of build-all to be run in parallel, and this can be acheived on the command line by running

$ crossbow run 'build-all@p'

but it's annoying having to do that so the task definition it's self should accept the flag - eg:

tasks:
  build-all@p:
    - build-js
    - build-css
  build-js:
    - lint
    - webpack
    - uglify
    - manifest
  build-css:
    - sass
    - cssmin

now this would work

$ crossbow run build-all

use async-done pattern for end of tasks

[email protected]

Watchers should receive all reports, even after error

'tasks' directory should be optional/configurable + allow multiple

should support .sh files out of the box

should populate ENV vars with Crossbow options/config

remove npmscripts confusion

currently we read the package.json and use the npm scripts fields to offer tasks to run.

This has turned out to be quite buggy so revert for launch

Tasks should be able to return their own tear-down logic

switch to 'yargs' for parsing CLI

escape watch patterns that contain { }

should output times in nicer fomat

for long running tasks

cross task value-store

Should be deliberately brittle, but if a pro user knows the exact sequence of their tasks, it would be nice to have a way for task A to produce a value (such as VM coming online and giving an IP) and then for task B or C to pick that up

use case:

1. Start a bunch of docker containers
2. Query the one running nginx for the machine IP + container port (to obtain the dev url)
3. Proxy this address with Browsersync/ngrok etc.

should support object literals in public .task api

support for cbfile.js

to replace gulp, this is a requirement

add `watchers` task for listing available watchers

watchers need 'block' option

eg: Running webpack after a watcher is triggered can take upto 10s - this is an example where you'd want any subsequent triggers to be ignored until the task has completed

add `tasks` command for listing top-level runnable tasks only

This would differ from the 'tree' command which shows everything. Sometimes you'll want to just see the main tasks you've defined

should accept 'config' options inside 'config' top level option

move tracker$ into context

each task gets a 'context' object, the tracker$ observable should be accessible there.

module.exports = function (options, context) {
    context.tracker$.subscribe((x: TaskReport) => console.log(x));
}

Tasks should support descriptions

Should beatify stack traces

re: https://github.com/sindresorhus/ava/blob/master/lib/beautify-stack.js

Immutable & Rx can lots of lines to stack traces, let's always clean them

Accept inline functions

To complete the 'better than gulp' story, we need to add support for inline functions

• allow inline functions to be resolved
• add tests for resolving
• add tests for running chains of inline functions
• update reporters to show inline functions

should support non-arrays in public .task api

Should always log input file being used

add @bg adaptor

Some tasks (such as watchify) need to be started effecitvely as daemons - implement @bg adaptor
to allow this

yaml

watch:
  # Run sass compiler
  # then run browserify in the background
  before:
    - sass
    - browserify

  # Now watch .scss files and compile sass
  watchers:
    'scss/**/*.scss': ['sass']

tasks:
  # Create the alias 'sass' for running locally installed node-sass
  sass:       '@npm node-sass --input scss/core.scss --output dist/styles.css'
  browserify: '@bg watchify app/bundle.js -d -o dist/bundle.js'

json

{
    "watch": {
        "before": ["sass", "browserify"],
        "watchers": {
            "scss/**/*.scss": ["sass"]
        }
    },
    "tasks": {
        "sass": "@npm node-sass --input scss/core.scss --output dist/styles.css",
        "browserify": "@bg watchify app/bundle.js -d -o dist/bundle.js"
    }
}

should handle error stack traces better

warn when configuration file was not found

silent error currently

should support --before flag for executing tasks before a watcher

only enter interactive mode if a 'default' task is not specified

applies to run + watch

interactive mode for watchers

$ crossbow watch -i

should show the available watchers

should support -e flag to temporary cross-task environment vars

cb.watch should return 2 streams - the task tracker + file-change events

interactive run should show tasks from `tasks` directory

default config files in root ignored

interactive run should show a preview of chid tasks

in gulp-mode, should use locally installed crossbow-cli

This allows cb.task to work, etc

rename 'config' to options

currently we have the top level keys.

config:
tasks:
watch:

'config' is used for task options and should be names as such to free us to use the 'config' key for actual configuration such as cwd etc

Should allow env vars to be passed to child processes

Should allow tasks in raw object literal form

When a single task is given in the CLI, set to parallel run mode

If there's a task defined such as build-all with the @p flag (meaning run all immediate children in parallel)

  build-all@p:
    - test/fixtures/tasks/error.js
    - test/fixtures/tasks/slow1.js

currently, if you run...

$ crossbow run build-all

then test/fixtures/tasks/error.js and test/fixtures/tasks/slow1.js will be put into a Parallel Group and a failure/error in any of them should not affect sibling tasks.

However, because the default mode for the top-level tasks is 'series', this means that even though build-all is a ParallelGroup, an error in task 1 will render this tree invalid.

solution: Always run in Parallel mode if one 1 task given. The moment there're are two or more tasks, eg:

$ crossbow run build-all build-css

then we class this as a sequential l task run and run as normal (requiring each task to complete before beginning the next)