• move current CLI to an external package start-simple-cli (node_modules/.bin/start will remain the same)
• create new start-babel-cli that will call start-simple-cliafter require('babel-register') and require('babel-polyfill')
  • no more babel-node explicit dependency
  • cleaner NPM scripts:

"scripts": {
  "start": "start ./tasks"
}

npm start build
npm start dev
npm start lint
npm start test
npm start tdd
npm start cover
npm start travis

How to use angular cli with this project?

https://github.com/start-runner/postcss
please add basic plugin for frontend as like postcss, sass, stylus
I will be grateful for the plugin for rollup-buddler
Your project is not very popular due to lack of documentation. But I really like the idea. Very convenient api

I've created a decompress plugin for start and get this error:

yarn start testsomething
yarn run v1.5.1
$ node packages/cli/src/index.js testsomething
/home/luii/Dokumente/git/start/packages/reporter-verbose/src/index.ts:1
ReferenceError: _70d‍ is not defined
    at Object.<anonymous> (/home/luii/Dokumente/git/start/packages/reporter-verbose/src/index.ts:1)
    at Module._compile (/home/luii/Dokumente/git/start/node_modules/pirates/lib/index.js:91:24)
error An unexpected error occurred: "Command failed.
Exit code: 1
Command: sh
Arguments: -c node packages/cli/src/index.js testsomething
Directory: /home/luii/Dokumente/git/start
Output:
".
info If you think this is a bug, please open a bug report with the information provided in "/home/luii/Dokumente/git/start/yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

This is my plugin:

import plugin from '@start/plugin/src/'
import { DecompressOptions } from 'decompress';

export default (outDirRelative: string, options?: DecompressOptions) =>
  plugin('decompress', async ({ files, logFile }) => {
    const path = await import('path')
    const { default: decompress } = await import('decompress')
    const { default: movePath } = await import('move-path')
    
    return Promise.all(
      files.map(async file => {
        try {
          const outFile = movePath(file.path, outDirRelative)
          const outDir = path.dirname(outFile)

          logFile(outDir)
  
          await decompress(file.path, outDir, options)
          return await { path: outDir, data: null, map: null }
        } catch (error) {
          console.error(error)
        }
      })
    )
  })

And this is in the tasks/index.ts:

export const testsomething = () => 
  sequence(
    find('packages/plugin-decompress/test/fixtures/file.tar'),
    decompress('tasks/')
  )

I'm a graphic designer. I design a volunteer logo. I can design it for you.

The tasks file in the docs uses ES6 syntax (import/export), which start-cli is not able to parse natively by default which makes it gives a slightly misleading error: Unable to find "tasks.js" file, please check it again

It should give a more faithful error, like "unable to parse" or something. The docs probably should also use ES5 syntax?

Awesome project btw, just found it and trying it out.

Hello Kir,
As I tried, we can not do something like this:

function test() {
    return start(
       [ loadNames('./names.txt'), loadNames('./names2.txt')] , //They should run in parrallel
        hello('Hello'),
        logName()
    );
}

It's nice if you can make it possible.

Hey. I'm about to introduce next major version relatively soon, with simplified tasks API and better API for tasks runner itself. Some details from future migration.md:

Start

Repositories

Start became a monorepo.

Pros:

• much easier to maintain
• no start-start-preset
• no babel-preset-start

Cons:

• ???

Runner

import Runner from 'start';
import Reporter from 'start-pretty-reporter';

const runner = Runner(Reporter());

export const build = () => runner(
  // ...
);

With this naming our core concept became much more clear: there are tasks and tasks runners. You have to wrap tasks with runner.

"External" input

runner itself is another function in which you can pass an "initial" input:

runner(...tasks)('input!')
  .then(console.log)
  .catch(console.error);

So no more start-input-connector:

export const tasksRunner1 = () => runner(
  function task2(input) {
    console.log('input from previous runner': input);

    return Promise.resolve();
  },
);

export const tasksRunner2 = () => runner(
  function task1() {
    return Promise.resolve('output');
  },
  tasksRunner1()
);

And start-watch became really beautiful:

export const dev = runner(
  clean('lib/'),
  watch('src/**/*.js')(
    runner(
      read(),
      babel(),
      write('lib/')
    )
  )
);

Tasks

Refactoring

Tasks were slightly simplified:

export default (options) => function myTask(input, log, reporter) {
  console.log('input:', input);
  log('hey from My Task!');
  console.log('original reporter:', reporter);

  return Promise.resolve('My Task output');
}

So in the simplest case task is just a single named function which should return a Promise.

Reporters

Default reporter

console.log is no more a default reporter for Runner.

Refactoring

Reporters were splitted into composed functions:

export default (name) => (type, message) => console.log(name, type, message);

@effervescentia @tunnckoCore @laggingreflex @nikolay @eisisig I was thinking about scoped packages like @start/runner, @start/clean and so on. But unfortunately start username is already taken on NPM. So I wrote to the author – radio silence, wrote to NPM support – they can't help even with abandoned empty accounts...

Rename the whole project? Or leave it as is with start- naming convention? I'm ok with both, but I need your opinion.

import Runner from '@please/runner';
import Reporter from '@please/reporter';

yarn please build
yarn please test

🤔

Pros:

• we can start (damn) everything from scratch with 0.1.0 versions for every package
• more searchable name? with pleasejs/please as a main repo

Cons:

• you have to rename and republish your tasks and presets as well – a lot of work (or not?)

What do you think about please? The major changes described above will be implemented regardless this naming issue.

Hey! I was looking for Gulp alternatives and the pitch for this one is good, it looks very usable as far the API goes. It's currently very JS-centric though, so it would be great to have an example of how I would use this for more general build tasks (with Stylus or Sass to get CSS, Pug or Markdown to get HTML files).

Are this kind of examples planned?

Hi, start is great. Looking on it almost one year. And finally consider to plug it in my flow. It would be the core of my day to day flow.

But I'm thinking for this that I may need in some cases to pass specific things to each task. For example glob patterns for the start-files task.

Something like

start dev 'lib/**/*.js'
start dev '**/*.js'

But I believe it won't be need only for that task. So I think the start CLIs should pass rest argument after the task name to that task. And because each task is just a function which returns start(task1, task2, task3) it can be passed to it.

export const dev = (args) => start(
  env('NODE_ENV', 'development'),
  files('build/'),
  clean(),
  files(args[0]),
  watch((file) => start(
    files(file),
    read(),
    babel(),
    write('build/')
  ))
)

So in advance in that task could be done some arguments parsing, with minimist for example.

I need all this, because I don't want to transpile specific directory, or all of my js files in the root project - the test.js file for example. In most cases I have one simple index.js file and one test.js file in the root of the repository/project/package. But in some cases I may need to transpile more than that index.js. So I want in my preset to set index.js path as default, but to be able to change it through the cli if I need.

I was going through the plugin types file and I was wondering: shouldn't the return type of the default export be StartPlugin or StartPluginAsync instead of StartPluginSync?

Since the default export is an async function expression, it will implicitly use a Promise to return its result.

For more robust loading and bundling.

edit: I mean, adding module and jsnext:main fields in the package.json file.

and a bit off-topic: tests are very big need. I don't think simple tests like this are enough. :) See start-rollup tests for real example of 100% coverage :)

I'm not sure, but yea, just to mark it here. I'm moving to use Atom instead of Sublime, so I'm curious if we can integrate it there.

Something like ctrl + shift + p and then start test for example.

@deepsweet wonder what's your opinion on letting the user pass some extra input to the plugins?

Currently we're limited to files as input, but I have a case where i would like to measure some file sizes as first step and pass those sizes to another plugin further in the sequence. The sequence looks something like this [measureFileSizesBeforeBuild, cleanDist, copyAssets, build, printFileSizesAfterBuild], where printFileSizesAfterBuild needs sizes from measureFileSizesBeforeBuild to output difference. I thought it would be easiest to just return additional prop resolve({ files, sizes }) and pass that trough the chain.

To make it work i guess a tiny change would be required in

{ reporter, files, ...additionalProps } and then spreading additionalProps in payload to pluginFn()

Hei there,

Just recently found out about this task runner and I'm lovin it so far! It provides simple task based runner and really useful in a monorepo project. I actually prefer NPM scripts over task runner, but for large monorepo project it'll inevitably become tedious to maintain and sync across multiple packages.

Now start, provides ability to orchestrate build stanza right from a root of monorepo, without much complexion. Really like it!

I noticed that less and ava were originally supported as plugin but not yet migrated to the current start monorepo. Is there any ETA in when they'll be migrated? Or is there any pointer if I were to implement custom plugin for them in the current version of start?

What're the differences with gulp?

Just like gulp 4.x do.

I think it's a good idea, because yarn start default looks really weird.

BTW, I discovered start three days ago, then I tried it as soon as I can. It's really cool! I have already used it in my own project!

Hi,
I don't really know how to put this.
So, i'm sorry if it's the wrong place :/

I develop a plugins for using Stylus with Start
start-stylus
github
I would love to get your feedback if you discover some bugs or if i do some things wrong :)

Thank and i love Start !!

👍