experimenting with api

[anithri]

Some ideas around #94

[jondot]

this looks really interesting - i now fully understand the idea of plugins and REALLY like it, totally makes sense.

one thing i'm starting to think about -- maybe we just execute the function the user gives us as-is without saying exec(..)?

so for example in the given scenario, we leave it completely for the user to decide how to use yarn:

plugins:{
 yarn: (..., attributes)=> myownexec(makeparams(attributes))
}

and we don't care what myownexec is. it can be calling shell, it can be using Yarn Javascript API directly -- or any npm module the user finds right.

This effectively cuts down lines of code completely in the plugin infrastructure -- which I feel is a good signal too, as well as opens up the ability for people to decide creatively: shell? javascript? maybe I run python?.

any thoughts?

[anithri]

The 2 challenges with bring-your-own that I can see are

1. logging. with sh or proposed wrap-script we can do some of the logging, without a wrapper it's on the user.
2. libraries. To keep the size of .hygen.js manageable when adding plugins, users are going to need to have some reusable libraries, and a place to put them. I think especially true for those using hygen-add. Global npm packages would work, but sort of separates the templates from the helper's they'd need.

1 is not a show stopper, but we'd need to make sure it was easy for them to do.

I don't have a good answer for 2.

edit: clarity

[anithri]

Now that I've written a bunch of templates, I have a better idea what I want. And for me plugins aren't it.

I can see 3 use cases for plugins.

1. Execute some code that returns data to be used in the template
2. Execute some code that does something as a side effect like a database entry or an api call
3. Actually generate some files.

I'm addressing these from the context of 'fat index.js, thin template.t'

Case 1 can be addressed within the generators index.js, and requires no changes to do so.

Case 2 could be done with the current setup, but with a cleanup: function like params:. At which point being able to execute arbitrary code before and after template generation should remove need for it in the template frontmatter.

Case 3 can mostly be addressed by templates and sh:, but inevitably someone will have a use case

[anithri]

published #119 to replace this.