Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Start tasks via API #177

Closed
Akkuma opened this issue May 22, 2016 · 6 comments
Closed

Start tasks via API #177

Akkuma opened this issue May 22, 2016 · 6 comments
Labels
Milestone

Comments

@Akkuma
Copy link

Akkuma commented May 22, 2016

It would be nice if there were a static method to use to start the tasks programmatically, much like gulp.start currently can do . I took a look at it seems like this could be "faked" until it is baked into fly.

@lukeed
Copy link
Owner

lukeed commented May 22, 2016

Does this.start() accomplish what you're describing?

@Akkuma
Copy link
Author

Akkuma commented May 22, 2016

this.start() doesn't accomplish this. The scenario is the following. I have a package that handles plugins and each plugin provides a function to build the plugin. Each plugin can use anything they want, so theoretically each plugin has their own build tool.

My directory would roughly have:

flyfile.js
scripts/
  |_  build.js

The parent package looks for x-plugin, reads the dependency's package.json, gets the path to a build file (build.js in this example) and then require(pluginBuildFile). The build.js needs to execute Fly to start a tasks/tasks in my flyfile.js via API outside of the context of a task.

Here's an example of me "hacking" this functionality into my project

var reporter = require('fly/lib/reporter');
var spawn = require('fly/lib/cli/spawn');
var creed = require('creed');

creed.coroutine(spawn)(process.cwd())
  .then(function (fly) {
    reporter.call(fly)
            .emit('fly_run', {path: fly.file})
            .start(['build']);
  });

@lukeed
Copy link
Owner

lukeed commented May 22, 2016

I'm not sure that I fully understand what you're trying to accomplish, so I'm going to guess & carpet-bomb you with a couple options.

Plugins route

You can "install" your plugins locally and then use them as normal fly-plugins.

{
  "devDependencies": {
    // install from a private repo?
    "fly-plugin1": "git+ssh://github.com/<user>/<repo>#<branch>",
    // install from local linked
    "fly-plugin2": "*",
    // install from local file
    "fly-plugin3": "file:../plugin3/build.js"
  }

The "local linked" requires npm link from that folder. Docs

The "local file" is explained here and here.

Fly needs its plugins to be prefaced with "fly-" in order to parse/recognize them; hence the "fly-plugin1", "fly-plugin2", etc.

At that point, you can have a main flyfile.js with:

exports.default = function * () {
  yield this.source('src/**/*')
    .plugin1({opts})
    .plugin2({opts})
    .target('dist');

  // third plugin has its own source/target
  yield this.source('plugin3/app')
    .plugin3({opts})
    .target('plugin3/tmp');
}

Each plugin's index.js should have a module.exports that looks like any other Fly plugin. THere are lots for you to look at & mimic. There's also some docs on this.

// .../plugin1/index.js
module.exports = function () {
  this.filter('plugin1', function (data, opts) {
    // ... stuff
  });
};

Tasks route

You can also export entire tasks from your plugin sub-dirs.

exports.plugin1 = require('./path/to/plugin1');
exports.plugin2 = require('./path/to/plugin2');
exports.plugin3 = require('./path/to/plugin3');

yield this.start(['plugin1', 'plugin2', 'plugin3']);

These can also be run in parallel.

Each plugin "controls" its own source, destination, etc:

// .../plugin1/index.js
module.exports = function * () {
  // have to run 'source' from the flyfile.js root
  // because that's where the plugin is initiated from
  yield this.source('plugin1/src/**/*.js')
    .target('dist/p2'); // will be sent to root + dist/p2
}

"Mono-repo" route

You can also just manage everything from the single flyfile.js. It will be probably get a bit lengthy, depending on the amount of task "uniqueness" from directory to directory.

You can check out the tail-end of #171 for info on how to easily manage the pathing of all your sources and targets.

With the {parallel: true} feature, you can get a lot done at the same time.

// flyfile.js
exports.default = function * () {
  yield this.start('common'); // do bunch of common stuff to all dirs, prepare?
  // wait....
  yield this.start(['plugin1', 'plugin2', 'plugin3'], {parallel: true}); // do each unique task
  // wait ...
  yield this.start('finish'); // closing common actions
}

@Akkuma
Copy link
Author

Akkuma commented May 22, 2016

You probably missed the above, since I posted it shortly after you responsed:
Here's an example of me "hacking" this functionality into my project's build.js file

var reporter = require('fly/lib/reporter');
var spawn = require('fly/lib/cli/spawn');
var creed = require('creed');

creed.coroutine(spawn)(process.cwd())
  .then(function (fly) {
    reporter.call(fly)
            .emit('fly_run', {path: fly.file})
            .start(['build']);
  });

These aren't fly plugins. These are components/extensions for a proper package. To be more specific, this is a browser extension that is being modularized. Each component of the extension can be built as its own separate extension for quick testing. The extension we ship out to customers needs to build each component and add the necessarily files to the manifest.json. The main extension needs to find each component, have each component build itself, and provide additional data to include that component in the main extensions. Additionally, each component of this extension could have its own build process. In fact, the current main extension uses grunt, which may not be ripped out until we've finished modularizing it, so there is no access to this.start as fly is not used there at all.

In gulp I can trivially do this, which solves my needs

var gulp = require('gulp');
require('../gulpfile.js');

gulp.start('default');

Each component then can be built for inclusion in the main extension trivially.

@lukeed
Copy link
Owner

lukeed commented May 22, 2016

Ah, I see.

Fly can't do this right now because it populates internal variables after being spawn, which means they're not accessible with a standard require().

That said, you could still achieve this same build architecture with options 2 & 3 that I posted above.

Another option, too, is to create a flyfile for each directory, then loop through with a node script and run fly in each directory, passing the -f flag

@lukeed lukeed added the future label Jun 20, 2016
@lukeed lukeed modified the milestone: 2.0.0 Sep 27, 2016
@lukeed lukeed mentioned this issue Oct 4, 2016
6 tasks
@lukeed
Copy link
Owner

lukeed commented Oct 10, 2016

Added in #218

@lukeed lukeed closed this as completed Oct 10, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants