We make the bridge as a child pages app of Nuxt 3

[medz]

I have been trying to upgrade Nuxt 2 projects to Nuxt 3 for the past two months, but the actual situation is not optimistic. There are many third-party dependencies and other issues to deal with.

In addition, the support of the bridge is very limited. In fact, I have a particularly bold idea!

Since Nuxt 3 & 4 support multiple pages app, why don’t we try to make the bridge support this mode? Let the routes be mixed together.

The root nuxt app is the latest Nuxt 3, and the sub pages app is Nuxt 2 + bridge. In this way, we can upgrade gradually without having to change dozens of files to upgrade a feature.

The most important thing is that we can directly use Vue 3 + Nuxt 3 & 4 when writing new pages, and for old pages, we still keep the Nuxt 2 method.

In terms of compilation, I think it is compiled into two different products. Enter different routes to load Vue 2 or Vue3.

In the two months I have been using the bridge, I feel more and more that we need a similar upgrade path. In this way, we don’t have to consider whether the old project needs to modify the API, so that we have enough time to refactor the page for upgrading.

The bridge approach is difficult to use now. For example, if meta: true is enabled and the head of the option API is not fully migrated to useHead, all SEO & Meta will become invalid during SSR. There are many similar differences.

Nuxt 2 legacy users are almost all using it in the formal production environment. Each feature upgrade means that hundreds of files and thousands of codes need to be modified.

Therefore, I think using sub pages app, compiling it into two apps. Then relying on nitro to load different apps on different paths can speed up our upgrades. And it is not easy to have problems.

[medz]

@wattanx Any suggestions?

[wattanx]

Do you mean nuxt 2 and nuxt 3 coexist?
Is it possible to do so again?
(I think there is a bridge because those cannot coexist.)

[medz]

Yes, let Nuxt 2 and Nuxt 3 coexist~

I noticed that the bridge uses the latest nitro, so the nitro version of the bridge is consistent with Nuxt3. Therefore, we can use different paths to load different Nuxt apps.

If this is implemented, we no longer have to modify a large number of files every time a new feature is enabled. Instead, our newly developed content can directly use Nuxt 3, and the old apps of Nuxt 2 can be gradually refactored to Nuxt 3 + Vue 3.

My biggest pain point at the moment is not how steep the upgrade path is (Nuxt + Vue upgraded to version 3), but that the project that was originally fully launched does need to be upgraded to the new framework. But I have to continue to use Vue 2 and Nuxt 2 for development, all of which was done before it was fully upgraded to Nuxt 3. The technical debt has been expanding since then.

[medz]

In addition, the coexistence I mentioned is not runtime coexistence. The old code is mounted as a sub pages app under Nuxt 3, and then the routes of the Nuxt 3 app are mainly used. The routes not defined under Nuxt 3 pages are mounted to the sub pages app (Nuxt 2 or bridge). After compilation, they are also independent nuxt apps, but different paths determine whether to load Nuxt 2 or Nuxt 3.

I think this can greatly speed up the upgrade. For example, I have a fully launched Nuxt 2 app with hundreds of pages and thousands of files. It took me two months to gradually upgrade to the bridge, and many features have not been successfully upgraded (meta, vite, asyncData).

But we always have new requirements to add to the project, which forces me to continue to use Nuxt 2 apis for development. If sub pages app is supported to mount Nuxt 2, then we can develop new requirements with Nuxt 3, and we can also refactor the modifications of old requirements into Nuxt 3, and the rest will be upgraded when we are free.

The current bridge model forces similar medium and large projects to upgrade to every small feature of the bridge very difficult.

PS: The biggest obstacle is that Nuxt 2 is incompatible with Nuxt 3's asyncData APIs, and there is almost no Options API documentation.

For example: before, head could return asyncData or data data, but the bridge could not. The bridge simply extracted head to setup, which would lead to incompatibility.

[wattanx]

I think it is better to use load balancer or cloudfront behaviour to distribute the routes.