Zip plugin loader

[dktapps]

THIS IS A PROPOSAL

Before getting mad in the comments, please note that this is a change proposal. It doesn't mean this will definitely be implemented.

Description

.phar has been the standard for public plugins for many years. However, it's inconvenient and esoteric.

The only reason to use Phar in the general PHP world is because .phar files can be run like .php files using the php executable. However, no one runs plugin .phar files directly anyway, so this is a moot point.

Justification

Zip plugins would have the following advantages:

• Easier to pack a plugin - no special tools needed, just right-click and zip on Windows
• No suspicious unphar websites needed to view contents (they probably make almost all of their business from PM plugin devs)
• Poggit CI would become mostly redundant - the linting and release parts would still be useful, but the phar building would be unnecessary
• Half of DevTools commands would become obsolete
• Consistent with other industry standard stuff like .mcworld, .mcaddon and .mcpack which are all dressed-up zips
• Way easier for third-party non-PHP tools to read plugin contents (e.g. to analyze plugin.yml) - no need to write your own Phar implementation

However, the following downsides:

• No "obfuscation" from the esoteric Phar format anymore. This might upset people that want to sell plugins without having their code readable. However, it's not that difficult for the right person to discover /extractplugin in DevTools.
• Noobs will be able to download source code zips of plugins and run them, potentially with missing dependencies. However, this is a problem that already exists with zip2phar nonsense and folder plugins anyway.
• PhpStorm doesn't index code files in zips. This might make it a bit less convenient to develop plugins that depend on other plugins.

Past precedent

This was implemented by a plugin in the past by @alejandroliu as seen here: https://github.com/Muirfield/pocketmine-plugins/tree/ZipPluginLoader-1.2.0/ZipPluginLoader

However, a modern implementation of this would be drastically simpler.

Alternative methods

[Matze997]

I would like to see those changes Poggit could start to only offer .zip plugins from now on and when pm7 releases phar plugin support can be removed completely The change should be forced slowly or just add support for both types Then everyone would be happy I guess

[MINTEDCLICKS]

yeah pls

[jasonw4331]

Which types of zip archival would be supported and what features within the spec would be supported?

I'd be interested to see pocketmine allow for password protected zip archives to be loaded with the password specified somewhere.

[dktapps]

I haven't actually thought about the password protecting stuff.

I think encrypting stuff in that manner is probably better left to plugins.

[NhanAZ]

.phar .zip why not folder? :(

[dktapps]

5917

[dktapps]

I'm currently leaning towards a custom file extension like .pmplugin in a similar manner to .mcpack and friends.

[dktapps]

One downside that just occurred to me is that developing a plugin that depends on another plugin might get a bit more inconvenient if zip becomes the standard, as PhpStorm won't automatically index code found in zip files.

[Bqleine]

Another downside to zip is that some linux systems don't have zip utilities installed by default since zip is rare in the linux ecosystem. The tar format is mostly used instead along with the tar utility.

I'm currently leaning towards a custom file extension like .pmplugin in a similar manner to .mcpack and friends.

According to the php documentation, PHAR files may be of zip or tar format instead of the custom phar format, using this would keep the same extension / usage while being easier to unarchive. So the format would be a tar/zip archive with .phar extension and the stub located in .phar/stub.php.

[dktapps]

Plugins don't need stubs. We don't need to bring phar or ext-phar into the picture at all.

[SOF3]

One downside that just occurred to me is that developing a plugin that depends on another plugin might get a bit more inconvenient if zip becomes the standard, as PhpStorm won't automatically index code found in zip files.

Many plugins already have a composer.json, which is more friendly for static analysis. Those who care about importing paths might as well just use composer.

[dktapps]

Many plugins already have a composer.json

Many more don't. The ones using composer are far from being the majority.

[dktapps]

For posterity: When_ used by a file included from a zip (e.g. zip://plugins/MyPlugin.zip/src/Main.php), __FILE__ and __DIR__ don't include the zip:// URI prefix, meaning that attempting to access files relative to __FILE__ and __DIR__ won't work correctly automatically. This is probably a bug in ext-zip. We can solve this by using phar:// (which does support zip natively, funnily enough).