Project status

[lowlighter]

Hi 👋 !

It's been a few months since the latest release and they weren't too many updates on this project 😅
As it got quite huge it is a lot of work to maintain it, and because I was pretty busy in life I couldn't dedicate much time on it recently.
I currently have some holidays planned but once I get back from them I'll start looking back slowly through this repo inbox and see which issues and pull requests are still revelant (even if they were auto-closed by the inactivity bot) and answers discussions, after which I'll start treating them if no-one is currently working on it.

In the meantime, thanks a lot for your ongoing support 🙇 !

PS: If you have issues/prs you'd like to be checked in priority, you can post them in this thread. Cannot make any guarantee they'll be treated super fast, but they'll at least be higher on my worklog 🙂

[real-yfprojects]

It would be nice though if you weren't the only maintainer.

[lowlighter]

Yeah definitely 😅

I think however the codebase may be currently too complex for people (and new contributors in general) to really take over.

I'm actually exploring the possibility of refactoring and switching the whole codebase to typescript/deno.
A v4 would definitely be a huge amount of work, but I think it could be worth it.

Mainly the TypeScript support, URL imports and security sandbox would make it possible to reduce the app size by a lot (not installing all dependencies thanks to tree shaking, "extras" flags can be entirely removed, load a specific plugin version from a previous release, etc.) and make it easier to contribute and fix as typing would be known.

The big part would mostly be the engine rewrite (the plugins/templates probably won't change that much, apart from added typing) but this could be a good opportunity to fix some design choices (mainly uncouple base/core plugins from other plugins, unify and simply the configuration options).

This would also offer the possibility to run the plugins as standalone within a reasonable amount of time, which means they could be reused in other apps, deployed as serverless functions, etc. Also deno can be compiled into a single executable, so it'd be possible to make a real cli

The serverless possibility would be really a plus I think, as it'd allow true previews in PR (like using vercels) but will also let people deploy their own instance more easily instead of relying on the action. Of course it won't be possible for all options (like the indepths features or heavy plugins) but it'd allow more flexibility overall as you could mix serverless for quick refresh plugins and actions for more intense plugins that you don't want to update too frequently

I'm still looking into it and maybe it won't happen, but I think that it may render this project more accessible and friendly
Idk what anyone thinks about this though, maybe people would disagree

[lowlighter]

Ideally, if I need to choose additional maintainers I'd like them to be able to be somewhat familiar about the engine/architecture of the app, and to at least be able to create a whole new plugin and template (or be capable of adding significant features)

So that's why I'm thinking that a refactor may be the solution to make these requirements reachable more easily

[real-yfprojects]

Ideally, if I need to choose additional maintainers I'd like them to be able to be somewhat familiar about the engine/architecture of the app, and to at least be able to create a whole new plugin and template (or be capable of adding significant features)

For sure, they should ideally prove themselves by becoming a core contributor first.

[Andre601]

Not entirely sure how the inactivity bot is configured, but I hope it doesn't mark as inactive if the issue/PR was created and simply didn't get any replies/activities within a timeframe... Feel like that's a bad aproach to dealing with inactive stuff...