Paying tech debt 2026

[LukasKalbertodt]

It's been a while since we took some dedicated time to clean up Tobira's code base or generally do things just for the maintainability. Some tech debt has accumulated over time and it would be nice to tackle at least some of that this year.

For now, this issue is just to loosely collect tasks! @owi92 please feel free to just edit this comment to add points.

Updates

• React 19 Update to React 19 #1598
• Juniper
• MeiliSearch (and SDK) Update minimum MeiliSearch version #1567

Refactoring

• Backend: move more things into model and clean types across api and other places (making everything more consistent)
• Generally go through code to identify similar patterns and see if things can be written in a better way. The code has grown and grown and I'm sure there are tons of opportunities to extract common logic, styles or whatever. In the frontend, I feel like we could be able to make better use of a "general component library", i.e. have a set of basic components to reduce code duplication, improve visual consistency and make it faster to add new features.
• Make the event/series waiting/status stuff more consistent and similar. Also see The distinction between waiting and ready events might not make as much sense (anymore) as we thought #509
• Maybe make eventById API work with Tobira ID and OC ID, same for playlist and series. That should cut down a lot on almost identical route definitions.

Frontend build system

• New Frontend build system?

By now, there are tons of build systems vastly faster than webpack. We unfortunately use quite a few features and hooks of webpack to do certain things, making a switch non-trivial. But maybe it is possible and maybe some of those build steps should be solved differently anyway.

Current problems:

• Slow & no HMR
• Sometimes crashes due to memory exhaustion (after a longer time)
• Sometimes "Unsafe call of a(n) error type typed value" errors without reason, fresh build fixes it
• Adjusting translations in en.yaml only affects i18n type checking after restart
• ...

Other

• Make UI tests less flaky or not flaky at all. Like actually tackle this problem heads on.
• Stop panicking in the backend when index.html or style.css is not present in debug mode. (This just confuses new devs and is annoying for all devs)
• Add backend integration tests Add backend integration testing (API and other stuff) #856
• Add more UI tests (after solving the flakiness problem)
• Better code splitting in the frontend. Currently we only put Paella in its own bundle, but most of our main bundle is code for ~manage pages, which most users will never see. Code splitting: split frontend bundle into multiple parts #257
• Update or replace softprops/action-gh-release@v1 #585

[LukasKalbertodt]

Re Juniper 0.17 update: I first thought it was fairly easy, but looking further into it, it turns out to be quite hard. The main problem is that the derive(GraphQLScalar) was changed. While nice in theory it does not allow us to return a Value::Object anymore. But we have a few graphql scalars that deserialize as objects, e.g. TranslatedString and ExtraMetadata. The only way I currently see of keeping our current behavior is to implement all traits manually, including (this is the bummer!) a few #[doc(hidden)] traits. They being hidden inside the macros module strongly implies they can be changed in minor version bumps and are only for internal use. We don't update Juniper often, so maybe its fine... but it's not amazing. There is graphql-rust/juniper#975 which is kind of what we want, but not quite, and its already there since 2021 and doesn't look like it's merged anytime soon. One could also open an issue bringing to attention this loss of functionality and maybe they fix it. But I also don't have high hopes for that.