Potential migration from Nuxt.js

[heyhippari]

While Nuxt.js is serving us pretty well, it is also fairly limiting.

For example, it is preventing us from bundling this client into the server. It also somewhat limits our control over every part of the client, and community plugins are often outdated and barely maintained.

As such, this issue is meant as a proposal and discussion for a migration out of Nuxt, as part of the move to Vue 3, and as a place to prepare said migration.

---

Requirements

This is a preliminary list of everything that would need to be done in order to move out of Nuxt.

This list is subject to change.

• [x] Set up a skeleton project and tooling
• [x] Set up vuetify
• [x] Set up vuex
  • [x] Migrate root module
  • [ ] Migrate submodules
  • [ ] Migrate plugins
• [x] Set up vue-router
• [x] Set up vue-i18n
• [x] Set up a layout system
• [ ] Migrate components
• [ ] Migrate pages over and setup routing
• [ ] Set up authentication
• [ ] Migrate plugins

Considerations

This makes the migration a bit more complicated and a bit more involved, but ultimately gives us much more control over how everything is setup and how everything works.

The good thing though, is that we can more or less start now, migrate in small parts and track Vuetify 3's alpha stages. We will also be much more up to date.

[heyhippari]

First observations from preliminary work on the vue3 branch:

• Vuex stores are partly migrated. The process is easy and mainly resolves around exporting an object containing actions, mutations, getters and state, which Nuxt would create automatically.
• Layouts are working through a Vite plugin. This should be easily replaceable, when we need to, as it essentially intercepts routing and builds a nested route with the same path, with the layout components.
• Routing already works, but routes need to be defined manually (as expected). It simply needs some time and migrated pages and we're good.
• Vuetify is still a bit early. While some components work, a bunch of mandatory components for our use (v-text-field, for example) are not implemented yet. Furthermore, the lack of documentation for v3 is proving to be a challenge. What I suspect to be Vuetify's composable (useVuetify()) doesn't import, leaving us without breakpoints, theme controls, etc.
• Vuetify on Vite still needs a bit of work (related to the previous point, it's still early alpha, so it makes sense).
• Locales are working already, even with the locale switcher half-borked. Migrating the translations is basically copy-paste, now that setup is done

And some points of interest for the migration:

• v-app was moved out of layouts. Since we now have access to the actual app template, we can avoid having to mess around with this in each layout, thus keeping the same v-app instance between all layouts.
• With the previous point, it is also now possible to move generic layout-independent components such as snackbar, audio-controls and player-manager out of the layouts and up to the app itself.
• Composition is explicitly encouraged by every library. As such, the migrated components on the vue3 branch have been rewritten to use the Composition API.
• vueuse, a large set of pre-built composables, has been added as a dependency. This allows us to skip writing a bunch of code for a lot of common things, from registering event listeners to reacting to various browser APIs.

Overall, this migration work is a great opportunity to fix some design issues and pretty much all the limitations we have with the current Nuxt-based build. The move out of Nuxt doesn't take as much time as I would have thought, since most things are already setup after about a day of work.
We are somewhat limited in testing with what is available on Vuetify, but it is possible to pre-migrate components and they should mostly start to work once more Vuetify components become available.

I'm pretty confident that this is a good path forward for the project :smiley:

[heyhippari]

Some more explanations about the vue3 branch itself:

As Vite is a completely different thing from Nuxt, I started the Vue 3 branch as an orphan. This means it has no history.

A new Vite project was created and files are individually added through a checkout from master, then migrated. This allows us to migrate everything piece by piece, without having tons of unused or plain broken files.
Some light file structure changes are being implemented (Around the Vuex store, for example) to make things a bit cleaner now that we have more control over everything.

The process for eventually making the vue3 branch would be as follows:

• Rename the master branch to vue2
• Rename the vue3 branch to master

This will keep the original history available, while making the Vue 3 port the main branch. However, contributors might have to hard reset their branch or re-clone the repository.

Do note that this process is not expected to be done until the vue3 branch is at feature-parity with the master branch, which is probably going to take a while (There's no estimation currently).

[Extarys]

Is there some easy tasks I could maybe help with? If I'm not that confident I might not touch it as I wouldn't want to ask a thousand questions either but... trying :stuck_out_tongue:

[heyhippari]

Currently it's very much still in the early stages :) I'm also taking the opportunity to rewrite everything to the Composition API (which is sort of needed, as most Vue 3 libraries have adopted it as the default) and refactoring some things (For example, I am almost done with rewriting the header of the home page, completely changing how the progress bar segments are handled to reduce the amount of code and the complexity of it on our end).

I would say that once Vuetify is a bit further along and once we have at least the authentication going, PRs against the Vue 3 branch would be fair game, but before that it's essentially just laying the basics and tentatively migrating some components to get a better idea of how it'd work and get things in place :)

[heyhippari]

Some relevant discussions in regards to architecture: #1329

[igorjacauna]

And what about only change to composition api and wait for nuxt 3 that will be launched in beta in August 2021?

[heyhippari]

I don't think Nuxt 3 will fix most of the technical limitations we have and, even if it fixes some of them, it still limits us a lot for the future. I think it's better for the future of the project to move to more "raw" Vue and get us out of the shackles of Nuxt early.

There are also non-technical reasons, though it's debatable because of the more personal and ideological nature of them.

Essentially, I'm not really fond of the way the Nuxt 3 development has been handled. While some internal discussion and a set direction is normal for an open source project (We are having internal discussions about Jellyfin 11 at this moment and trying to decide a direction), entirely developing the next version behind closed doors and preventing any community input is, in my opinion, a bad way to run an open source project.

It soured me a bit on Nuxt, though I still think it's a good framework, because I don't want to depend entirely on something we as a community essentially have no say on.

For everything else (Vuetify, Vue, Shaka Player, etc), the community is part of the development process. You can submit RFCs, make pull requests and generally get involved with the development. I've gotten answers from the Vuetify devs directly on some v3 features that weren't documented yet and they invited us to give feedback as we progress through the migration.

With Nuxt 3, you can't. It's all made behind closed doors, without any input, and then just released as-is. And, in my opinion, that makes it a non-starter.

Moving to the composition API is a given, at this point, but using it on Vue 2 seems like more trouble than its worth (Vuex 3 doesn't support it, for example. Nuxt 2 isn't made for it so it feels clunky to use), but I think taking the time to move out of Nuxt will pay dividends later on (For technical reasons, the ideological reasons are personal and, while they influence the decision a bit, I try to mainly stay neutral and see things from a maintainability standpoint first and foremost).