> In fact, the split will make the situation more complex. > Now we require the `package.json` stuff and need to handle complex > dependency cases (like the apisix-base I mentioned in that issue). > These problems are not existent if we don't split the plugin. > We have to develop a custom new package manager to solve these new > problems. Why bother to create more problems?
split the plugin, don't mean split the depend repo, if we wan't marketplace. in fact, the APISIX is also support the method. /apisix/plugins/ext-plugin. > Also, it is very tough to sync the schema between Dashboard & Ingress > control & other components, if each plugin has its own schema version. if the plugin is independent. the user can write their own plugins, and install it by apisix-dashboard or other method for dynamic installing. > BTW, even for developers, the split is also disaster when you try to > upgrade APISIX. The more we split, the more chain reaction we will > meet. > Dependency hell warning! split the plugin, don't mean split the depend repo, if we wan't have marketplace. if we want have the marketplace, the version dependency is necessary. in fact. Ecosystems cannot depend on APISIX. and the thirdpart. Most software that supports plugin, has the marketplace, eg vscode, emacs, vim or manual installation mode. All similar software faces this problem. > Compared with similar open source projects: > 1. Envoy doesn't and can't split filters out of the core > 2. Kong used to split some of the plugins out. But now they are merged > them back. i only proposal refactoring the plugins code organization. split the independent repo or independent directory could discuss. it only just depends on if we have marketplace. > We should not lead Apache APISIX to the wrong path, right? Only through discussion can we know whether the direction is correct or not. Instead of someone saying right is right, saying wrong is wrong Zexuan Luo <spacewan...@apache.org> 于2022年3月15日周二 12:46写道： > In fact, the split will make the situation more complex. > Now we require the `package.json` stuff and need to handle complex > dependency cases (like the apisix-base I mentioned in that issue). > These problems are not existent if we don't split the plugin. > We have to develop a custom new package manager to solve these new > problems. Why bother to create more problems? > > Also, it is very tough to sync the schema between Dashboard & Ingress > control & other components, if each plugin has its own schema version. > > BTW, even for developers, the split is also disaster when you try to > upgrade APISIX. The more we split, the more chain reaction we will > meet. > Dependency hell warning! > > Compared with similar open source projects: > 1. Envoy doesn't and can't split filters out of the core > 2. Kong used to split some of the plugins out. But now they are merged > them back. > > We should not lead Apache APISIX to the wrong path, right? > > Chao Zhang <zchao1...@gmail.com> 于2022年3月15日周二 11:48写道： > > > > Hi Fei, > > > > I have some doubts about the proposal: > > > > 1. Term Compile is too generic, could you give us some examples about > this > > process; > > 2. How could can help developers to integrate APISIX and this plugin, so > > that developers can test the plugin successfully; > > 3. I didn’t get the key point of package.json, the entry point code > > actually can be specified (such as from the init.lua). > > > > Chao Zhang > > https://github.com/tokers > > > > On March 15, 2022 at 10:54:47, Fei Liang (bsch1...@gmail.com) wrote: > > > > stable, the addition of the plugin will be dynamic and frequent. >
