flow-cli icon indicating copy to clipboard operation
flow-cli copied to clipboard

Plugin system for flow-cli

Open bluesign opened this issue 3 years ago • 3 comments

Issue To Be Solved

Flow-cli is getting bigger and more powerful every day, maybe it is time to think about extensions ( plugins )

This issue is to kick off some discussion

(Optional): Suggest A Solution

I think npx [0] model can be very good here, as now we have some persistent place to put stuff. For example recent flowser edition can be something like:

flow plugin flowser/cli start ( which will somehow get related stuff from flowser/cli repo from github ) and download to user app settings as a package.

There are some security considerations for sure, but it can kick off some community contribution, without putting load on core devs.

[0] https://www.npmjs.com/package/npx

bluesign avatar Nov 21 '22 17:11 bluesign

How I currently added flowser is a pattern I feel we could use in the future as part of this plugin system. So any tool that wants to be added to the CLI just needs to implement the interface having methods Install, Run and then CLI can just import that module and run it like it was done here https://github.com/onflow/flow-cli/pull/693 I feel this can work but open to feedback, but yeah my idea was that with first tool Flowser added this pattern then works for any community built tools and we want to be open on adding more of others for sure.

Mentioning npx did you mean use the npx to run the install script or use npx like system?

devbugging avatar Nov 22 '22 14:11 devbugging

I was thinking a bit on the opposite direction:

Something like everyone can make a flow-cli plugin, you install the plugin, it integrated with flow-cli. ( ofc flow-cli also provides a way to install the plugin )

Flowser case is a bit different ( as we just install an app there ) but if we think flowser was a TUI app for a second. It would be nice to use:

flow plugin flowser blocks to list blocks for example. Somehow I see cli as superapp composed of independent modules mainly. ( which all expose some functionality with cobra )

so technically lsp can be a plugin, emulator can be another plugin, signing modules can be plugin etc.

Main problem I see is rolling back a version, or running a new version requires CLI install to previous or next version. If we could somehow made them independent plugins, maybe we could manage multiple emulator versions in single CLI.

bluesign avatar Dec 23 '22 12:12 bluesign

I see what you mean, it's for sure interesting idea to explore. I think for GUI tools it makes sense to integrate them as we did with Flowser and we will continue to do so, since they require GUI. For other CLI tools or just tools without a required GUI we can go that path. I think the best thing we can do is to just provide an example of both and then let community follow those. I think a good candidate for second approach could be some parts of overflow which I already was discussing with @bjartek

devbugging avatar Dec 23 '22 18:12 devbugging