You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
So far I have installed many of our etherpad plugins from GitHub repos, e.g. JannikStreek/ep_123 (sometimes also leveraging branch names, some plugins being forks). Since the adjustment of using the live plugin manager for installing also build time given plugins, the process is bugged.
Problem
There are currently two problems, which make the installation process of such plugins quite confusing:
Plugins are correctly placed in root node_modules folder after installation. However, when the server starts and migratePluginsFromNodeModules is called, the plugins are NOT taken from the node_modules folder, but are installed from the npm registry with the same name. However, as I haven't published my plugins, it's using just any npm package with the same name. As many of my plugins are forks, it basically uses the parental project instead of my plugin (which is published). Thats quite confusing and took me some time to debug.
Adding plugins at a later point in time via pnpm install ep_123 does add the plugin again to the node_modules folder. But restarting the server does not copy those plugins to the correct location, as this is dependent on the file var/installed_plugins.json. If this file is already existing (created during first server start) the second run completely ignores later installed plugins. Again quite confusing.
Suggested solution
At least for 1) as a quick fix, I made a small change to installer.ts method migratePluginsFromNodeModules to exclude GitHub links:
if (!_info.resolved || _info.resolved.includes('github')) {
// Install from node_modules directory
await linkInstaller.installFromPath(`${findEtherpadRoot()}/node_modules/${pkg}`);
} else {
await linkInstaller.installPlugin(pkg);
}
Maybe it should be the other way around, only use installPluginwhen a npm url is given?
For 2) I would suggest to maybe recreate this file on startup? Not sure as I do not know the exact architectural decisions behind this.
The text was updated successfully, but these errors were encountered:
Did the adjustments with the plugin installer script solve the issue. You can add the plugins via the --path argument then locally regardless if there is another plugin available locally.
Context
So far I have installed many of our etherpad plugins from GitHub repos, e.g.
JannikStreek/ep_123
(sometimes also leveraging branch names, some plugins being forks). Since the adjustment of using the live plugin manager for installing also build time given plugins, the process is bugged.Problem
There are currently two problems, which make the installation process of such plugins quite confusing:
Plugins are correctly placed in root node_modules folder after installation. However, when the server starts and
migratePluginsFromNodeModules
is called, the plugins are NOT taken from the node_modules folder, but are installed from the npm registry with the same name. However, as I haven't published my plugins, it's using just any npm package with the same name. As many of my plugins are forks, it basically uses the parental project instead of my plugin (which is published). Thats quite confusing and took me some time to debug.Adding plugins at a later point in time via
pnpm install ep_123
does add the plugin again to the node_modules folder. But restarting the server does not copy those plugins to the correct location, as this is dependent on the filevar/installed_plugins.json
. If this file is already existing (created during first server start) the second run completely ignores later installed plugins. Again quite confusing.Suggested solution
At least for 1) as a quick fix, I made a small change to
installer.ts
methodmigratePluginsFromNodeModules
to exclude GitHub links:Maybe it should be the other way around, only use
installPlugin
when a npm url is given?For 2) I would suggest to maybe recreate this file on startup? Not sure as I do not know the exact architectural decisions behind this.
The text was updated successfully, but these errors were encountered: