CLI --use <plugin> <config>

[jasonkuhrt]

-- edit

I have refocused this issue to be _only about point 3 below_.

I am considering creating a duo plugin library that provides more structure than is currently available.

What I would like to standardize:

1. plugin is wrapped in a constructor possibly taking plugin configuration
2. plugin has standard signature (not sure what standard yet)
3. plugin used via $ duo --use should be able to accept config too in some standard way

I imagine point 3 as something like these?:

$ duo client/index.js --use foobar 'a b c'

$ duo client/index.js --use foobar '{a:1, b:2, c:3}'

[matthewmueller]

sweet, so I can give you my thoughts on (1) and (2):

1. plugin is wrapped in a constructor possibly taking plugin configuration
2. plugin has standard signature (not sure what standard yet)

The standard plugin structure is to take a function and return either a synchronous, asynchronous or generator function. Here's what I mean:

// sync
function plugin(opts) {
  return function jade(file, entry) {
    // some transforms
  }
}

// async
function plugin(opts) {
  return function jade(file, entry, fn) {
    // some transforms
    fn()
  }
}

// generator
function plugin(opts) {
  return function *jade(file, entry) {
    // some transforms
  }
}

As for (3), I'm thinking we could do something similar to what jade does with their -O, --obj <str> CLI option. Here's a reference: http://jade-lang.com/command-line/.

[jasonkuhrt]

As for (3), I'm thinking we could do something similar to what jade does with their -O, --obj CLI option. Here's a reference: http://jade-lang.com/command-line/.

I don't see any examples in jades docs, but I assume this:

$ duo client/index.js --use foobar '{a:1, b:2, c:3}'

would be a valid duo counterpart, no?

Also why not add data file support too:

$ duo client/index.js --use foobar options.json

# or YAML?
$ duo client/index.js --use foobar options.yml

# or a JavaScript file that exports a function which must return a configuration?
$ duo client/index.js --use foobar options.js

# or a consolidated plugin configuration file?

# Each plugin would have its config under a key-based namespace named according
# to that plugin's name, eg: { foobar: {a:1, b:2, c:3}, blah: { z:1 }}

$ duo client/index.js --use foobar --use-config options.json #or
$ duo client/index.js --use foobar --use-config options.yml #or
$ duo client/index.js --use foobar --use-config options.js

# using short flags, U for --use-config
$ duo client/index.js -u foobar -U options.json

# and, of course, -U would accept a literal:
$ duo client/index.js -u foobar -U '{foobar:{ a:1, b:2, c:3}}'

@matthewmueller However, to achieve this (3) I believe duo has to be modified at the core:

• Allow --use to accept a config argument as seen above
• Forward respective parts from --use-config to the --use instances

No?

[dominicbarnes]

If we're working on changing up the plugin architecture, let's not forget to address #346 as well. We need a clean way to distinguish between per-file and per-build plugins. (perhaps they need separate code-paths altogether)

[jasonkuhrt]

@dominicbarnes I am changing this issue to be strictly about config-passing on the CLI as I believe it to be a feature resilient against whatever happens in #346 and beyond. CLI config-passing is just a plain general problem. It may need to evolve to support different plugin types but fundamentally the idea will hold.

[jasonkuhrt]

@matthewmueller I am going to pursue a pull-request supporting duo --use <plugin> <config>. Please tell me now if this will be a wasted effort. Seems like we all agree in its usefulness though.

[cristiandouce]

There is a similar PR already #276

[jasonkuhrt]

@cristiandouce Thanks, I've chimed in there. From what I understand of that proposal I am considerably more in favour of my design so far here.

[matthewmueller]

$ duo client/index.js --use foobar '{a:1, b:2, c:3}'

Yep, I like this much more.

[matthewmueller]

I think we should only allow single arguments as well to keep the implementation clean and to encourage consistent API design. Basically to your point in #276 (comment).

[jasonkuhrt]

@matthewmueller sweet glad consensus is building. I am going to get to work on that then.

[stryju]

given '{foo: /foo/}', will the options.foo be parsed as regexp?

also, any updates?

[jasonkuhrt]

FYI I'm no longer a duo user so won't be active on this issue. Cheers.

[stryju]

well, the only reason for me is working on a analytics.js related project