plugin bootstrapping and code generators

[garrettjstevens]

@rbuels I thought it would be nice to have a sample run-time plugin that does something basic that we could use to experiment with. I could work on this if you want, but I'd need a bit of direction since I'm not entirely sure how we are going to implement them.

[rbuels]

It would be a good idea to look at what Atom, vscode, and other plugin-based javascript systems do for their plugins.

[garrettjstevens]

Not just for runtime plugins, but for plugins in general, I really like the idea of having a Yeoman generator for plugins like VS Code has for their extensions. If we could have several different hello-world-style templates that create plugins with different combinations of pluggable elements, I think it would go a long way toward making plugin creation easier and more consistent.

[rbuels]

Yes a yo generator and/or some boilerplate projects would be great

On Sat, Dec 1, 2018 at 7:49 AM Garrett Stevens notifications@github.com wrote:

Not just for runtime plugins, but for plugins in general, I really like the idea of having a Yeoman generator for plugins like VS Code has for their extensions https://code.visualstudio.com/docs/extensions/yocode. If we could have several different hello-world-style templates that create plugins with different combinations of pluggable elements, I think it would go a long way toward making plugin creation easier and more consistent.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/GMOD/jbrowse-plugin-template/issues/32, or mute the thread https://github.com/notifications/unsubscribe-auth/AAEgFcJarhN1aT5i0stSedOlV2IM-Rvnks5u0qT9gaJpZM4Y2O3O .

[elliothershberg]

I think it's worth noting @garrettjstevens and I have discussed this idea several times when thinking about the plugin template and GMOD/jbrowse-components#1146 . While the template is fairly automated now and includes an example, it could still be neat to have a generator tool for making plugins instead of a template. I think the value would be in having sub-generators to scaffold the boilerplate for various types of widgets.

[cmdcolin]

Personally I'm a bigger fan of having working example plugins rather than generators, and people can base their work off examples that we have

[garrettjstevens]

We have a boilerplate template here: https://github.com/GMOD/jbrowse-plugin-template. We may open another issue later to do a generator for plugins.

[elliothershberg]

@rbuels and I were talking about the prospect of revisiting generators for plugins. One potential implementation to base ours off of could be the RedwoodJS generators. They rolled their own basically, and didn't use a scaffolding tool.

Their generator code is here: https://github.com/redwoodjs/redwood/tree/main/packages/internal/src/generate

I've found generators to lead to a really nice developer experience in other cases where I was using tools that had them, and felt it greatly reduced the learning code. I realize that might not be the majority sentiment here, but I thought I'd re-open another time to discuss 😄

[cmdcolin]

i'd advocate, if needed, to use the "create-react-app" model of generating a boilerplate

[cmdcolin]

moved to our plugin-template repo. might not strictly belong here either but it is a external plugin concern

[cmdcolin]

just re-iterating some interest in this

I do like things like 'create-react-app' where a command line helps instantiate the template

Example

yarn create jbrowse-plugin myplugin
yarn create jbrowse-plugin --template minimal myplugin2

[ihh]

I like this idea too, perhaps in the context of an organized effort towards getting some key constituents' jbrowse1 plugins ported to jbrowse2