[Idea]: Put core plugins inside swup's main repo

[hirasso]

Describe the problem 🧐

We recently had a silent regression in fragment plugin after an update to swup to allow aborting visits. That happened because we currently have no way to test if a release of swup is compatible with it's plugins.

Thankfully there was a test in place in fragment plugin that fired the next time we worked on that plugin. But it was a pretty confusing situation, as we needed to find out where the issue was coming from (it was NOT coming from our latest changes to the plugin).

Describe the propsed solution 😎

To prevent this problem from happening again, we could think about putting the plugin inside swup's main repo, as for example Alpine.js is doing it with it's core plugins.

That would make it possible to test the plugins within the context of swup itself.

PRO:

• better reliability between swup and plugins

CON:

• probably harder for newcomers to contribute
• we will probably need considerable time to make this change

Alternatives considered 🤔

Find another way to trigger tests for plugins every time we want to make a change to swup. A quick search yields this result: https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows. But this would be very vendor specific in contrast to the monorepo approach.

How important is this feature to you? 🧭

Nice to have

Checked all these? 📚

• I have read and searched the official docs
• I have checked discussions and existing issues for related problems
• I agree to follow this project's Code of Conduct
• I have provided all necessary information to the best of my knowledge

[daun]

I remember this coming up in the past. The monorepo idea is very tempting! It's a very big effort upfront but will make changes to tooling and documentation across all plugins much more straightforward.

The main argument against it (in my opinion) is related to your second argument contra: plugin visibility. GitHub itself has become a way of discovering packages. Individual per-plugin repos have the big advantage of being very discoverable, easy to link to, easy to show up in suggestions on feeds, etc. One can immediately judge the scope of each plugin, the description, open issues, number of stars, etc. Collapsing all of that into a monorepo would muddle that considerably. One can technically link to a plugin readme file in a package subfolder, but the experience is much worse in my opinion, see e.g. how the Alpine Astro integration presents on GitHub.

[hirasso]

Right! The visibility of the plugins would be less then optimal if they would live in a monorepo. Maybe there are solutions available that would maintain the visibility but would allow us to still do all the development work in a monorepo? I recently came across illuminate/collections, wich is a "subtree split" of the module, synced somehow from the laravel core repo (?).

Actually, all packages under https://github.com/illuminate look like read-only subtree splits.

I have no idea how they are doing it, but it could be an interesting route to solve the visibility problem.

[hirasso]

Looks like the relevant code for the automatic splits in illuminate/collections is located here:

https://github.com/laravel/framework/blob/11.x/bin/split.sh

They are using https://github.com/splitsh/lite, a tool to automatically create standalone read-only repos from a monorepo. There also exists a tool to merge multiple repos into one: https://github.com/hraban/tomono

Leaving these links here in case we ever decide to walk down monorepo lane 🚶

I have created a Q&A thread at at laravel/framework where I'll try to understand the complete picture: laravel/framework#51059

[daun]

That's a really smart approach! Definitely worth checking it out in detail and then seeing if we'd like to give it a try.