အနှစ်ချုပ်
အလွှာ နှစ်ခု ရှိပါသည်။ Core module သည် အဓိက host ဖြစ်ပြီး၊ module များကို ရှာဖွေတွေ့ရှိကာ မှီခိုမှုအစဉ်အတိုင်း တင်သွင်းပေးသည့်အပြင်၊ ERP တိုင်းလိုအပ်သော အခြေခံစွမ်းရည်များ (အတည်ပြုခြင်း၊ လုံခြုံရေး၊ DI၊ router၊ builtin အချက်အလက်၊ မီနူး၊ SPA chrome) ကို ပံ့ပိုးပါသည်။ Plugin များမှာ သင်ရေးသားသော plugin app များ ဖြစ်ပြီး၊ ကုန်ပစ္စည်းလက်ကျန်၊ POS သို့မဟုတ် HR စသည့် လုပ်ငန်းနယ်ပယ်အတွက် backend API၊ ဒေတာဘေ့စ် ဇယားနှင့် React မျက်နှာပြင်များကို ပါဝင်ပါသည်။
- Core = module တင်သွင်းခြင်းနှင့် အခြေခံ platform စွမ်းရည်များကို အဓိက ကိုင်တွယ်ပါသည်
- Plugin များ = plugins/<name>/ အောက်တွင် သင်ရေးသားသော ကိုယ်ပိုင် app များ ဖြစ်ပါသည်
- တင်သွင်းခြင်းသည် boot / browser load အချိန်တွင် တက်ကြွစွာ ဖြစ်ပေါ်ပြီး၊ compile အချိန်တွင် တစ်ခါတည်း ပေါင်းစည်းထားခြင်း မဟုတ်ပါ
- အခြား plugin တစ်ခု၏ src/ ကို import မလုပ်ရပါ — shared package၊ metadata dependency နှင့် export/inject ကိုသာ အသုံးပြုရပါသည်
1. ဖွဲ့စည်းပုံ အမြင်
Runtime တွင် ထုတ်ကုန်သည် core နှင့် ထည့်သွင်းပြီးသား plugin များ ပေါင်းစပ်ထားခြင်း ဖြစ်ပါသည်။ ရင်းမြစ်ကုဒ်သည် plugins/ တွင် ရှိပြီး၊ build များသည် available-plugins/ အောက်တွင် စုစည်းပါသည်။ Core က အမှန်တကယ် တင်သွင်းသည်မှာ installed-plugins/ အောက်ရှိ မိတ္တူများသာ ဖြစ်ပါသည်။
- Source — plugins/<name>/ — သင် တည်းဖြတ်ရသော နေရာ
- Available — base/available-plugins/<name>/<version>/ — quan-erp watch / build ၏ output
- Installed — base/backend/installed-plugins/<name>/ — core က အမှန်တကယ် တင်သွင်းသော နေရာ
- Folder အမည်၊ metadata.name နှင့် package အထောက်အထား တူညီရပါမည်
1base/ # core runtime (Docker)
2├── backend/ # core host process
3│ └── installed-plugins/<name>/ # active plugin copies
4├── frontend/ # SPA core (menus, chrome)
5└── available-plugins/<name>/<ver>/# staged builds
6
7plugins/<name>/ # your plugin app (edit here)
8├── backend/
9├── frontend/
10└── module.metadata.json # identity + dependencies2. module.metadata.json
Plugin တိုင်း၏ root တွင် module.metadata.json ပါရှိပါသည်။ Core သည် ထိုဖိုင်မှ module ၏ အမည်၊ ဗားရှင်း၊ လိုအပ်သော base လိုင်းနှင့် ရှိရမည့် အခြား plugin များကို ဖတ်ရှုပါသည်။ Metadata မှားယွင်းပါက discovery၊ install နှင့် DI တို့ ပျက်စီးနိုင်ပါသည်။
- name ကို install အတန်း၊ DI (@Inject(Service, "name")) နှင့် dependency map တွင် အသုံးပြုပါသည်
- requiredBasedVersion သည် လည်ပတ်နေသော core / @quan-erp/* လိုင်းနှင့် ကိုက်ညီရပါမည်
- Plugin အမည်ပြောင်းခြင်း သို့မဟုတ် pluginVersion မြှင့်တင်သည့်အခါ metadata ကို sync လုပ်ထားပါ
- တူညီသော ဖိုင်ကို available-plugins နှင့် installed-plugins build များသို့ ကူးယူပါသည်
| Field | ရည်ရွယ်ချက် |
|---|---|
| name | တည်ငြိမ်သော plugin id — folder အမည်နှင့် install အထောက်အထားနှင့် တူရပါမည် |
| pluginVersion | ဤ plugin ၏ ကိုယ်ပိုင် semver (မှီခိုသူများ pin လုပ်ရန်) |
| description | Module / install UI တွင် ပြသသော လူဖတ်နိုင်သည့် အကျဉ်းချုပ် |
| moduleEntryObject | Backend entry ၏ export အမည် (များသောအားဖြင့် "Module") |
| requiredBasedVersion | ကိုက်ညီသော core / @quan-erp/* base လိုင်း (ဥပမာ "1.0.0") |
| pluginDependencies | အခြား plugin အမည် → အရင် တင်သွင်းရမည့် semver range မြေပုံ |
1{
2 "name": "inventory",
3 "type": "",
4 "pluginVersion": "1.0.0",
5 "description": "Inventory management",
6 "moduleEntryObject": "Module",
7 "requiredBasedVersion": "1.0.0",
8 "pluginDependencies": {
9 "products": "^1.0.0",
10 "accounting": "^1.0.0"
11 }
12}3. Module မှီခိုမှုများ
pluginDependencies က ဤ module လိုအပ်သော အခြား plugin များနှင့် ဗားရှင်း အပိုင်းအခြားကို ဖော်ပြပါသည်။ Core သည် topological load order ဖြင့် မှီခိုရသော plugin များကို အရင် boot လုပ်ပြီး မှတ်ပုံတင်ပါသည်။ ပျောက်ဆုံးနေခြင်း သို့မဟုတ် မကိုက်ညီခြင်းသည် စနစ် စတင်မှုကို ပိတ်ဆို့နိုင်ပါသည်။
- Key များသည် ပံ့ပိုးသူ (provider) ၏ metadata.name တန်ဖိုးများ ဖြစ်ပါသည် (npm package အမည် မဟုတ်ပါ)
- Value များသည် provider ၏ pluginVersion အတွက် semver range များ ဖြစ်ပါသည်
- @Inject(Service, "other-plugin") သုံးခြင်း သို့မဟုတ် ၎င်း၏ export API များကို ပြန်သုံးသည့်အခါ dependency ကြေညာရပါသည်
- ဗလာ object {} ဆိုသည်မှာ plugin dependency မရှိခြင်း — core builtin များမှာ ဆက်လက် ရရှိနိုင်ပါသည်
- အခြား plugin ၏ src/ ကို import မလုပ်ရပါ — dependency ကြေညာပြီး export / inject ကို အသုံးပြုပါ
"pluginDependencies": {
"products": "^1.0.0", // provider name → semver of its pluginVersion
"accounting": "^1.0.0"
}4. Core က module များကို တင်သွင်းပုံ
စတင်သည့်အခါ core သည် filesystem ပေါ်ရှိ build များနှင့် module ဇယားကို ပေါင်းစပ်ပါသည်။ Installed ဟု မှတ်သားထားသော အတန်းများသာ အသက်ဝင်ပါသည်။ ထည့်သွင်းပြီးသား plugin တစ်ခုချင်းစီအတွက် မှီခိုမှုအစဉ်အတိုင်း backend ကို တင်သွင်းပြီး၊ နောက်မှ browser က frontend entry ကို တင်ကာ shared AppRegistry သို့ register လုပ်ပါသည်။
- available-plugins အောက်ရှိ build သည် Install လုပ်ပြီး installed-plugins သို့ ကူးမချင်း အသက်မဝင်သေးပါ
- Property @Inject သာ ပံ့ပိုးပါသည် — constructor injection ကို မပံ့ပိုးပါ
- အသေးစိတ်အတွက် Documentation → Backend → Module lifecycle နှင့် Frontend → Plugins lifecycle ကို ဖတ်ရှုပါ
- 01
ရှာဖွေတွေ့ရှိခြင်း
installed-plugins မှ module.metadata.json ကို ဖတ်ပြီး၊ module ဇယား (installed / active) နှင့် ကိုက်ညီမှု စစ်ဆေးပါသည်။
- 02
အစဉ်စီခြင်း
pluginDependencies မှ dependency graph တည်ဆောက်ပြီး၊ ပံ့ပိုးသူများကို စားသုံးသူများထက် အရင် တင်သွင်းပါသည်။
- 03
Backend
IPlugin entry ကို တင်သွင်းကာ @Module (provider၊ controller၊ entity) ကို မှတ်ပုံတင်ပြီး DI လုပ်ကာ၊ ထို့နောက် @OnInit / @OnAllModuleLoaded ကို run ပါသည်။
- 04
Frontend
ထည့်သွင်းပြီးသား frontend asset များကို serve လုပ်ကာ၊ plugin entry ကို dynamic-import လုပ်ပြီး၊ route၊ မီနူးနှင့် slot များ ထည့်သွင်းရန် register(AppRegistry) ကို တစ်ကြိမ် ခေါ်ပါသည်။
5. နောက်အဆင့်များ
Core stack ကို run လုပ်ပါ၊ plugin တစ်ခု scaffold လုပ်ပါ၊ ထို့နောက် CLI watch / install လည်ပတ်မှုဖြင့် ဆက်လက် တိုးတက်ရေးသားပါ။
- အခြား plugin ၏ src/ ကို ဘယ်တော့မှ import မလုပ်ရပါ
- @quan-erp/* နှင့် requiredBasedVersion ကို လည်ပတ်နေသော core နှင့် ကိုက်အောင် ထားပါ
- Folder အမည် = metadata.name ကို တစ်သမတ်တည်း ထားပါ
- Plugin အချင်းချင်း inject မလုပ်မီ pluginDependencies တွင် ပံ့ပိုးသူ အစစ်များကို စာရင်းသွင်းပါ