Create the FSK Animation Exporter Plugin

[SnaveSutit]

Source: https://github.com/SnaveSutit/bbanim-to-fsk

[JannisX11]

Hey, sorry this took so long to get a reply. There has been a lot going on.

As you might be aware, this type of submission doesn't follow the bundling requirements outlined in readme.md.
I do however understand that hosting the entire code in a shared repository is not ideal. Especially if the plugin is more complex or has a lot of boilerplate files like this one.

One compromise I could offer would be to update the guidelines and keep the source repository separate, but submit the plugin in here as a non-minified/uglified file. That way the plugin could still be reviewed as a relatively plain file and updates would show proper line diffs.

For context, this requirement serves the purpose of allowing a submission or change to be reviewed in the respective pull request.

[SnaveSutit]

I genuinely forgot this plugin existed... 😂

There is no "obfuscation" or "uglification" going on here, it's all minification. The shortened names is simply a side-effect of minification, as the bundler is attempting to remove as much data as possible.

Uploading the non-minified file as the main plugin file would cause the file size to increase drastically (from 19KB to 39KB in this case, and from 1,900KB to 9,600KB in Animated Java's case.), and those changes would be difficult to read as bundler code. So I don't think that's the best solution.

I have a couple alternatives:

• I could make a PR for each release with all it's changes on my source repo, and let you look over the changes there. Giving you a much clearer idea of what's changing, and allowing you to comment on and suggest changes to the PR directly.

• I could include the dev bundled plugin as the "source" for the file in the repository, while still using the minified file as the main plugin file. That way you get the bundled diff when I submit the PR to update, without the end-user needing to download more data.

The current guidelines lock plugin developers out of utilizing a lot of extremely powerful Github features, like CI, Actions, Releases, Codespaces, Wiki, Custom repository settings, tags, etc. So giving plugin developers the freedom to use your their own repository for their source code is something I highly recommend.

I'm of the opinion that the plugin submission process should be reconsidered with modern development practices in mind, as having a monorepo with every single plugin in it is not a good long-term solution, especially with the recent increase in submitted plugins. But we can discuss that somewhere else.

Edit

I think I lost the context of your original message while writing this, and I seem to have essentially re-iterated a few of the points you brought up. Whoops.