Upgrade live-plugin-manager to 1.0.0

[yacchin1205]

To fix #6330, upgrade the live-plugin-manager.

The live-plugin-manager has been updated to allow plug-ins to depend on several different versions of packages. Dependency packages are now managed by directory names that include version numbers, and symlinks to them are placed in the plugin_packages directory. Ref: https://github.com/davideicardi/live-plugin-manager/pull/90

Therefore, the conversion below (fs.realpath) would cause unexpected symlink resolution, I fixed that.

    plugin.realPath = await fs.realpath(plugin.location);

[SamTV12345]

Great. How will this solve the issue with the symlinked dependencies? If we still need to link to node_modules the link won't be created if it is already present

[yacchin1205]

Great. How will this solve the issue with the symlinked dependencies? If we still need to link to node_modules the link won't be created if it is already present

Thanks, I'll see how it works if the link already exists in node_modules. I will also check the results of the test, so please wait.

[SamTV12345]

Sure I'll wait

[yacchin1205]

I investigated a failed backend test with a plugin. It seemed to be a problem in the test code for each plugin, so I created a Pull Request for each one.

• ep_align: https://github.com/ether/ep_align/pull/131
• ep_font_size: https://github.com/ether/ep_font_size/pull/113
• ep_headings2: https://github.com/ether/ep_headings2/pull/129
• ep_image_upload: https://github.com/citizenos/ep_image_upload/pull/69

[SamTV12345]

Thanks for the fixes. I'm not really an expert and code JavaScript just for fun as my main work is Java. I'm happy that you could spot the mistakes :)

[SamTV12345]

I just released a new version for the plugins in our test pipeline. The ep_font_size plugin still reports that done has been called multiple times in hook in two tests https://github.com/ether/etherpad-lite/actions/runs/9229612289/job/25431647520 . Do you have an idea why?

[yacchin1205]

I just released a new version for the plugins in our test pipeline. The ep_font_size plugin still reports that done has been called multiple times in hook in two tests https://github.com/ether/etherpad-lite/actions/runs/9229612289/job/25431647520 . Do you have an idea why?

Thank you for your quick action! It seems that ep_font_size is failing to release a new version. The fatal: tag 'v0.4.60' already exists is printed when running the git tag command, and the v0.4.60 tag shows that it is a 2 month old commit, This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository. I think this means that the release may have failed for some reason in the past.

I assume that if you delete the current v0.4.60 tag in the repo and then run the release Action again, the release will be executed.

[yacchin1205]

Tests related to the upgrade had failed and are now fixed. This seemed to be caused by trying to install plugins with plugins i in the version before install-plugins was integrated into the plugins subcommand. Therefore, I have modified the workflow so that plugins can be installed with either install-plugins or plugins i.

I also checked the behavior when node_modules are already in place: When plugins install is executed, live-plugin-manager will place the downloaded package in src/plugin_packages/.versions under the directory name package_name@version. Then, create a symlink to the package_name@version directory in src/plugin_packages with the name package_name. etherpad-lite creates a symlink to the src/plugin_packages/package_name directory in src/node_modules by the pluginfw, so the following link will be created.

src/node_modules/some_package -(symlink)-> src/plugin_packages/some_package -(symlink)-> src/plugin_packages/.versions/some_package@target_version

If some package is already installed in src/node_modules/some_package by e.g. pnpm install, it does not seem to make any changes to that directory. For example, if the .pnpm directory is linked to src/node_modules/some_package, that link will be preserved.

Additionaly, when the checkForMigration of etherpad-lite is executed, it will run linkInstaller.installPlugin according to the contents of var/install_plugins.json, but since the packages that satisfy the requirements already exist in src/plugin_packages, so the process will be completed without downloading anything.

It would be great if you could confirm the changes!

[SamTV12345]

Tests related to the upgrade had failed and are now fixed. This seemed to be caused by trying to install plugins with plugins i in the version before install-plugins was integrated into the plugins subcommand. Therefore, I have modified the workflow so that plugins can be installed with either install-plugins or plugins i.

I also checked the behavior when node_modules are already in place: When plugins install is executed, live-plugin-manager will place the downloaded package in src/plugin_packages/.versions under the directory name package_name@version. Then, create a symlink to the package_name@version directory in src/plugin_packages with the name package_name. etherpad-lite creates a symlink to the src/plugin_packages/package_name directory in src/node_modules by the pluginfw, so the following link will be created.

src/node_modules/some_package -(symlink)-> src/plugin_packages/some_package -(symlink)-> src/plugin_packages/.versions/some_package@target_version

If some package is already installed in src/node_modules/some_package by e.g. pnpm install, it does not seem to make any changes to that directory. For example, if the .pnpm directory is linked to src/node_modules/some_package, that link will be preserved.

Additionaly, when the checkForMigration of etherpad-lite is executed, it will run linkInstaller.installPlugin according to the contents of var/install_plugins.json, but since the packages that satisfy the requirements already exist in src/plugin_packages, so the process will be completed without downloading anything.

It would be great if you could confirm the changes!

Thanks for the pr. I just rebased with the latest changes. I also found a good solution for backwards compatibility by fixing it in the script. With pnpm you can add aliases so I aliased install-plugins with run plugins i. That way we fixed it in the script. Besides that I am really impressed you managed to symlink the packages which is so awesome. 😁

[SamTV12345]

Tests related to the upgrade had failed and are now fixed. This seemed to be caused by trying to install plugins with plugins i in the version before install-plugins was integrated into the plugins subcommand. Therefore, I have modified the workflow so that plugins can be installed with either install-plugins or plugins i.

I also checked the behavior when node_modules are already in place: When plugins install is executed, live-plugin-manager will place the downloaded package in src/plugin_packages/.versions under the directory name package_name@version. Then, create a symlink to the package_name@version directory in src/plugin_packages with the name package_name. etherpad-lite creates a symlink to the src/plugin_packages/package_name directory in src/node_modules by the pluginfw, so the following link will be created.

src/node_modules/some_package -(symlink)-> src/plugin_packages/some_package -(symlink)-> src/plugin_packages/.versions/some_package@target_version

If some package is already installed in src/node_modules/some_package by e.g. pnpm install, it does not seem to make any changes to that directory. For example, if the .pnpm directory is linked to src/node_modules/some_package, that link will be preserved.

Additionaly, when the checkForMigration of etherpad-lite is executed, it will run linkInstaller.installPlugin according to the contents of var/install_plugins.json, but since the packages that satisfy the requirements already exist in src/plugin_packages, so the process will be completed without downloading anything.

It would be great if you could confirm the changes!

I just tested. Installing does work also with clashing sub dependencies. Unfortunately uninstalling seems to be broken. Do you have an idea why? I just did pnpm run plugins rm ep_align and nothing happened.

[SamTV12345]

@yacchin1205 Do you have time to fix this today? It would be awesome if we could merge your changes in the next 2.1.0 release of Etherpad. That would be really great :). Thank you for your effort.

[yacchin1205]

Do you have time to fix this today? It would be awesome if we could merge your changes in the next 2.1.0 release of Etherpad. That would be really great :). Thank you for your effort.

Thanks for fixing the test! I have checked the pnpm run plugins rm issue and have no idea of a fix, and a fix today seems hard for me.

Perhaps it is a live-plugin-manager's limitation, since nothing happened (src/plugin_packages/ep_align remained) in the same way with the previous version of live-plugin-manager (0.20.0). How about creating a new Issue or Pull Request to address the plugins rm issue? Again, thanks for your help!

[SamTV12345]

Do you have time to fix this today? It would be awesome if we could merge your changes in the next 2.1.0 release of Etherpad. That would be really great :). Thank you for your effort.

Thanks for fixing the test! I have checked the pnpm run plugins rm issue and have no idea of a fix, and a fix today seems hard for me.

Perhaps it is a live-plugin-manager's limitation, since nothing happened (src/plugin_packages/ep_align remained) in the same way with the previous version of live-plugin-manager (0.20.0). How about creating a new Issue or Pull Request to address the plugins rm issue? Again, thanks for your help!

You're welcome. Yes let's do that instead. Awesome work :)

[SamTV12345]

I think one of the problems of the live-plugin-manager is/was that somehow when we run the script it does not know anything about the installed plugins etc thus uninstalling does not work. That part seems to be a bit buggy. Maybe there is a race condition somewhere. When I start it with Etherpad that part of the code does work.

[yacchin1205]

I think one of the problems of the live-plugin-manager is/was that somehow when we run the script it does not know anything about the installed plugins etc thus uninstalling does not work. That part seems to be a bit buggy. Maybe there is a race condition somewhere. When I start it with Etherpad that part of the code does work.

Looking at the live-plugin-manager code, it seems that the list of plugins is not reloaded on initialization of PluginManager class, but only added when installation is performed. Etherpad instructs live-plugin-manager to install the plugin again at startup, so it seems to work as expected with Etherpad. Since this issue is important to me, I have created an Issue and would like to investigate the cause and consider improvements. #6419