Discussion: Plugin API

[JasonEtco]

Hey folks; I've been thinking about how plugins differ from using webhooks within a Probot App, and I think that there is some friction around differentiating the two. Currently, a "plugin" is a node module that is called like a function:

module.exports = robot => {
  myPlugin({foo: 'bar'});
}

And that's cool, but it doesn't feel like a plugin, it feels more like a function call (which really it is). As an example, Webpack does this differently:

const config = {
  ...
  plugins: [
    new webpack.optimize.UglifyJsPlugin(),
    new HtmlWebpackPlugin({template: './src/index.html'})
  ]
};

Do you folks think it could be a good idea to explore some kind of plugin configuration API like that? Maybe something like (but not exactly):

module.exports = robot => {
  robot.plugins([
    new myPlugin({foo: 'bar'}),
  ]);
}

Feel free to close this if you don't agree 👍

[hiimbex]

These are some very interesting ideas. 🤔 I'm not sure moving all probot plugins towards being more plugin-like is the best idea though.

I think maybe we could differentiate between plugins and apps and do some re-branding around that. I think plugins should be really small things like probot-scheduler or even the components of behaviorbot/welcome. And I think your ideas would be awesome for that.

But I think stale for example is really more of a stand-alone App, in that it's very complete. I was thinking about that re: probot/stale#55. Obviously we shouldn't not update it for existing users, but still, moving forward, I think there are definitely stand-alone probot Apps that really don't need further integration.

Just my $0.02 though 🙇‍♀️

[gr2m]

I think the fact that an probot app can be a plugin at the same time as great for composition. I would not change that

[bkeepers]

Just to clarify, when you say "plugin" you're talking about scheduler, but not "apps" like stale, right @JasonEtco? (The rest of this comment assumes that's what you meant. Sorry if I'm reading that wrong.)

First, I think we have a terminology issue that needs resolved. Since at least #89, "plugins" are what we've been calling the node modules that use probot. Meanwhile, scheduler, which is a reusable module used by "plugins", calls itself a "helper".

Without changing any functionality, I'd first like to propose we change terminology:

• plugins => apps - Akin to "react apps" or "rails apps", Probot apps are just node apps that have a dependency on probot and use features of the framework. They can be run standalone or combined with other plugins with the probot run command.
• helper => extension - Probot extensions are reusable modules that extend Probot itself.
  probot-scheduler is currently the only example, but there are a few others I can imagine, such as probot-command which would do slash command handling similar to what @jbjonesjr's snooze app does.

What does everyone think of that?

Do you folks think it could be a good idea to explore some kind of plugin [extension] configuration API like that? Maybe something like (but not exactly):

I like the idea of adding explicit configuration for extensions eventually. Since there's only currently one example in the wild, I think it feels a little to early to add an explicit API for it because we don't know how they'll be used. Will it be common to use multiple extensions in a single app? If so, an interface like you've suggested makes a lot of sense. But if apps at most use 1-2 plugins, something more like robot.use(extension) might be more appropriate.

[JasonEtco]

First, I think we have a terminology issue that needs resolved.

Agreed; I think your suggestion to use "App" to describe a thing built on Probot that you host and install in a repo, and "Extension" to describe some third-party code used in a Probot App (maybe along with some other code you wrote) is good. You were correcting in guessing what I meant 👍

I think it feels a little to early to add an explicit API for it

I see what you're saying; I'm thinking about long-term reusability of very specific actions that extend Probot Apps, but I agree that it's a little early. However, I do think that having some form of API around it early, however minimal, will make it easier for Probot users to build multiple apps with overlapping functionality.

I like the robot.use(extension) approach, it's the same as express which I think makes sense.

@bkeepers, feel free to close this out and reference it later when the "extension" conversation comes up again 🙌

[gr2m]

They can be run standalone or combined with other plugins with the probot run command.

you mean "combined with other apps", right?

I like the terminology 👍

I like the robot.use(extension) approach

+1

[jbjonesjr]

My only question about this terminology is how do you differentiate a probot-app that is probot + code and an app that is probot + other apps + code (maybe)?

Like if I wanted to just create a single app that includes things like auto-responder, stale, and welcome. The thing I deploy is the probot-app, but what are the other dependencies I included to make my app?

Combining apps into other apps seems weird... But maybe not?

I'm also interested in what it would look like to build my app without putting any real logic in index.js, but instead let it just call an init method (pass it robot) to make it more portable for more comprehensive apps (I'm sure there is some name for this pattern, but ¯_(ツ)_/¯).

[JasonEtco]

I'm also interested in what it would look like to build my app without putting any real logic in index.js

@jbjonesjr - I agree that that's a reasonable pattern, certainly one I've used (especially in express apps). I think that'd be a good use for the robot.use(extension) method.

Like if I wanted to just create a single app that includes things like auto-responder, stale, and welcome. The thing I deploy is the probot-app, but what are the other dependencies I included to make my app?

That's an interesting note; if you're using a Probot App inside your Probot App, does that first App become an Extension? 🤔 In this case, would you still use the robot.use() syntax?

I think we're overthinking this - I would say that a Probot App is what you deploy. Code brought in to your Probot App is considered an Extension. What do y'all think about this?

[bkeepers]

My only question about this terminology is how do you differentiate a probot-app that is probot + code and an app that is probot + other apps + code (maybe)?

The only analog I can think of is a Rails app vs a Rails Engine. Does that comparison make sense?

Currently, Probot apps can be deployed together, but unlike Rails Engines, each app is still isolated from the other. The fact that they're running in the same Node runtime is just a deployment convenience.

Until we have real world examples of apps extending the functionality of other apps, I'm not sure it's worth optimizing for the Rails Engine use case in Probot.

Does that make sense?

[gr2m]

Until we have real world examples of apps extending the functionality of other apps, I'm not sure it's worth optimizing for the Rails Engine use case in Probot.

What I plan to do for @hoodiehq is to create different bot accounts for different teams (code, documentation, editorial, community). These bots will consume & combine functionality from other bots, at least that is my plan. I find the current API very nice for that, but I have not yet tried it

[bkeepers]

The terminology change suggested in #207 (comment) is done. I don't think there's anything else actionable in this issue at the moment, so I'm going to close it.

Thanks @JasonEtco for bringing this up. I'm looking forward to seeing more examples of extensions in the wild and adding APIs to support it.