think of verdaccio plugin design

[joebnb]

this project i have great experience on using,i have use this 2 years,and it seems welecom to disscus and issue.so i want pull a disscussion of my thinking.
TL;DR
since use verdaccio V4 i have implemented and changed plugins and ui for fit work sence.there are a lot change of built in storage and built in ui changes,and i move this changes to plugin follow official site documentation.but there are some worry about this:

1. it's cant get any update since i move the built in plugin out as a new plugin
   • could verdaccio handle package as stream pipe like webpack loader ,and give plugin developer life cycles like ('pre-read','after-read','pre-steaming','after-steaming'),after this developer can custom all progress to implemention and arrange them to handle package,this would be make built in plugin reuseable and up to date.
2. ui plugin is huge and already useful,but not extensionable,i think too many users didn't want to rewrite all of this,but they prefer to change some actions（some actions i think is very usual and limited,we can built it in）
   • could ui plugin and db plugin give some alternative feature confing, in my case there are some uplink scoped package to show, so verdaccio support uplinks,support list package but it can't config the package list show cached uplink packagess or not.verdaccio could read remote package info but it can't view remote packages(it can't search,but i can type full name in search bar and show detail)

i'm not sure this thinking did match. It's for reference only

[juanpicado]

Hi @joebnb , thanks for opening this discussion, I've read your thoughts and I'd like to have some clarifications so I fully understand what you want to achieve.

could verdaccio handle package as stream pipe like webpack loader ,and give plugin developer life cycles like ('pre-read','after-read','pre-steaming','after-steaming'),after this developer can custom all progress to implemention and arrange them to handle package,this would be make built in plugin reuseable and up to date.

As far I understand here, you are willing to have some sort of lifecycle for different actions, as install tarball or fetching metadata, and you would like to have access via a plugin, that's correct?

ui plugin is huge and already useful,but not extensionable

I fully agree, but I don't know at this point how to make it extensional, I'd need help on this. I'm thinking in some sort of dynamically different parts of the UI.

,i think too many users didn't want to rewrite all of this,but they prefer to change some actions（some actions i think is very usual and limited,we can built it in）
could ui plugin and db plugin give some alternative feature confing, in my case there are some uplink scoped package to show, so verdaccio support uplinks,support list package but it can't config the package list show cached uplink packagess or not.verdaccio could read remote package info but it can't view remote packages(it can't search,but i can type full name in search bar and show detail)

Could you give me some examples, either with visualizations or whatever you consider I can fully understand your concept.

---

Thanks for taking the time to provide feedback, I'm having the same thoughts so far but I need user input to take action in the right way.

[joebnb]

plugin

As far I understand here, you are willing to have some sort of lifecycle for different actions, as install tarball or fetching metadata, and you would like to have access via a plugin, that's correct?

yes,in addition if it could arrange to handle package is more better, if there are 2 plugin change in same lifecycle how priority they should have may be a problem, especially these plugin are handle more than one lifecycle and they need change runing priority.

i think life cycle + steam should better,like thie have FETCHING_TARBALL and SAVE_TARBALL life cycle,my 2 plugin both depends on pre SAVE_TARBALL cycle.it could be arrage like:

(packge_info)->FETCHING_TARBALL[after streaming reday]-> (steaming)->plugin_1_handle | plguin_2_handle->(streaming) -> SAVE_TARBALL -> otherplugin life cycle

it need a lifecycle definition in plugin by plugin developer to declare this plugin works on which step,and make user(SRE) could arrage priority of them in verdaccio config.

if implement this, the built in storage plugin will decoupling from some sence,like i want develop a plugin to read tarball readme.md and save it to verdaccio db or save to cloud storage,i will only develope a plugin name verdaccio-save-readme.not verdaccio-save-readme-local-storage and verdaccio-save-readme-amazone

UI plugin

Could you give me some examples, either with visualizations or whatever you consider I can fully understand your concept.

UI plugin extensional is difficult i also not have good easy idea like you,but i think it could start also like plugin consider the user: 1 user 2 plugin developer .

user(SRE) may not have ability to change it by code,they could change ui only by config,plugin developer may do more things by develope.

user

for user we should think how may feature verdaccio was supported, and ui plugin did offer a UI to let user to use ui to interact with verdaccio.like searh bar behavior,package list did show some scope cached package...

in my case i change search bar to open a package detail page even it not found(verdaccio contain uplink maybe this package exist on uplink),verdaccio search bar more like a quick view input with complition.

plugin develop[er

for plugin developer we can think it in 2 angle,how to include ui part to developer's other project such readme render,versionlist,dependencies into small packages and other angle is how to implemet ui self.

if we split ui to smaller package,it would reuse in other project and show.

to implemet ui,i think we can get inspire for vue slot.we can pre define some slot like(navbar,home page content pre/after package list,package detail content,pakcage detail sidebar),this and develper could register these plugin like this

expoert default {
    position:'pos',
    component
}

config

- UI
    - plugin
        - package-count(detail-sidbar)
        - popup-notice(home-global)
        - homepage-banner(home-packagelist)
        - packagelist-ondemand(home-packagelist)
        - manage-package(home-navbar)
        - ....  

after this we should consider alternative about bundler to how to make npm package installed in node_modules work with ui,or should ui config seperate form config or implement a new cli command verdaccio --update-ui etc.

sorry for english not well

[joebnb]

i think current dissus also beacuse verdaccio plugin‘s architecture could not reuseable，if plugin enhanced, make develop plugin not consult to verdaccio origin code,plugin developer just think about how to finish my business when develope,will good for verdaccio environment and decrease disscus about features

[joebnb]

could i make some PR for my question and other peoples question and issues?

maybe my PR not follow your think please point out

[juanpicado]

I read briefly your response, I will BRB soon to this discussion, need to finish few things first. 👍.

[juanpicado]

if plugin enhanced, make develop plugin not consult to verdaccio origin code,plugin developer just think about how to finish my business when develope,will good for verdaccio environment and decrease disscus about features

At this point there are some request regarding improve plugin system, I agree on that, delegate more responsibilities to the plugins rather the core, but at this point there is no a suggestion how to achieve that (if you ask me I'm still thinking how to do it), somehow, here a list of related tickets.

• Multiple Authentication Plugins · Issue #1442 · verdaccio/verdaccio · GitHub
• Forcibly republish the package with the same version · Issue #1402 · verdaccio/verdaccio · GitHub
• Plugin System is weird · Issue #1394 · verdaccio/verdaccio · GitHub
• Collisions between main verdaccio and plugins configuration · Issue #928 · verdaccio/verdaccio · GitHub
• Harmonize configuration options · Issue #925 · verdaccio/verdaccio · GitHub
• Support for multiple access groups in plugins API (access, publish) · Issue #916 · verdaccio/verdaccio · GitHub
• Allow scopes for loading plugins feat: allow scopes in loading plugins #1867
• Allow middleware to add layers on different parts of the request (being, end, etc ...) add Prometheus /metrics and k8s /health endpoints #1815 (comment)

[juanpicado]

UI plugin extensional is difficult i also not have good easy idea like you,but i think it could start also like plugin consider the user: 1 user 2 plugin developer .

That's the problem, how to achieve this. I'm not sure if webpack could help on this. The UI is shipped bundled.

[juanpicado]

if implement this, the built in storage plugin will decoupling from some sence,like i want develop a plugin to read tarball readme.md and save it to verdaccio db or save to cloud storage,i will only develope a plugin name verdaccio-save-readme.not verdaccio-save-readme-local-storage and verdaccio-save-readme-amazone

Yeah, I expect to have more granularity on plugins, so any part of the system could be replaced by custom logic, but project still in (master) refactoring mode and will get there eventually.

[joebnb]

https://www.npmjs.com/package/verdaccio-local-storage-advance i have done #2658 in another way,although i was misleading from storage plugin and middleware introduction till choose wrong one to finish it.

the problem:storage plugin can't be multiple and i need access storage so if i choose storage ability i need implement storage plugin behavior

so, i think the auth plugin, storage did necessary exist.if i choose this for current requirement,it will trap develop some requirement in future