Closed Akkuma closed 7 years ago
Does this.start()
accomplish what you're describing?
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']);
});
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.
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
});
};
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
}
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
}
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.
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
Added in #218
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.