chore: upgraded playground to nuxt v3.16 in compat mode for nuxt 4
Upgraded the module to the latest version of Nuxt (3.16) with compat mode for Nuxt 4. Fixed some additional minor stuff in the module.ts file.
Hey @colinscz , I +1'd it by updating it to the newest newest version of Nuxt, including the other packages.
the pnpm.* entries added by pnpm when you run pnpm approve-builds and selected the deps?
missing pnpm lock file: when updating to 10.7.0 or 10.7.1, pnpm should ask if recreating lock file and node_modules: press Y and when selected the deps after pnpm approve-builds press also Y
... and then, commit and push pnpm lock file
You are correct, It didn't produce or ask for a new one after updating to 10.7.1, weird.
- pnpm i :: Done in 4.6s using pnpm v10.7.1
- pnpm approve-builds :: There are no packages awaiting approval
Pushed the lock file!
Hi, @justserdar I downloaded your fork and tried the playground (by the way you need to let TresCanvas be imported by the nuxt module because it has the server version)
I get this, the same if I tried to navigate to any other route
I cleaned up regarding your feedback. The span/div change if its breaking, we can let go off it for now. When I comment out the import it fails on my end too, local import works however.
Might need Daniel for this.
why using 3.16.0 when we have 3.17.3 released?
EDIT: we need to use original nuxt version and use pnpm.overrides or resolutions with latest version, I'll try to review this tmr, will ask here or at discord @alvarosabu
(the pr title is wrong since we're changing the dependencies at root and we need to ensure that changing the playground doesn't break existing projects with older Nuxt versions)
I cleaned up regarding your feedback. The span/div change if its breaking, we can let go off it for now. When I comment out the import it fails on my end too, local import works however.
Might need Daniel for this.
We don't need Daniel, we need to ensure we're not breaking anything, my suggestion will be to use this PR as a new major (breaking) or at least to use it in another new PR: in any case, we should use 3.16.0 as base "@nuxt/kit": "^3.16.0" and use resolutions to use latest 3.17.3 (with >= 3.16.0 at nuxt module props).
Nuxt 3.16.0 was a big breaking change: unhead 2, vue 3.5 and a few more breaking changes (including new features like Vue Lazy Hydration for example). I'm doing this on my Nuxt modules.
why using 3.16.0 when we have 3.17.3 released?
@userquin Good question, I'm not aware you guys are already beyond v3.16, I don't understand why @alvarosabu asks me to change things, if you're already ahead??
To recap after this while, this PR includes five things:
- [success] Fix the
better-sqliteissue like discussed on twitch stream. - [success] Push compatibility mode 4.
- [success] Upgrading to v3.16
- [success] Added vitest to test SSR on the pages via the div.
^ edit: I believe this is currently
breaking changes(this can be reverted). - [failed] Attempted to fix the not-locally imported TresCanvas, which failed without using the commented import route.
I was under the impression this PR was pushed to the side like my other PR. If you still need help with it, let me knw here or on discord. I'm really confused about the 3.17.3 bit..
Edit: @userquin
We don't need Daniel, we need to ensure we're not breaking anything
The only thing that doesn't work is this (existing problem, out of scope: given my PR title?):
Not working
// for testing purposes with auto-import disabled
// import { TresCanvas } from '@tresjs/core'
Working
import { TresCanvas } from '@tresjs/core'
The only breaking might be about the div change, again we can revert that or modify vitest. Let me know.
No, the main change is the package.json, that's why we should accept only small PR (ofc, sometimes there is no way), but in this case, my suggestion is to do small changes that doesn't break current version:
- your point 1
Then, if current Nuxt version supports compatibilityVersion, then include it in another PR without any change than the playground:
- your point 2
Then update to 3.16.0, should be breaking since 3.16.0 is breaking itself. I guess the SSR porblem is about Nuxt 3.16.0 and Vue 3.5.
About your last point, will try to check it tmr.
No, the main change is the package.json, that's why we should accept only small PR (ofc, sometimes there is no way), but in this case, my suggestion is to do small changes that doesn't break current version:
- your point 1
Then, if current Nuxt version support compopabilityVersion, then include it in another PR without any change than the playground:
- your point 2
Then update to 3.16.0, should be breaking since 3.16.0 is breaking itself. I guess the SSR porblem is about Nuxt 3.16.0 and Vue 3.5.
About your last point, will try to check it tmr.
@userquin We can let go of this PR and make it in smaller PR's, I am more inclined in that direction too. I can split it up in the coming days, but i'll try to drop by here or on discord first. Edit: Lemme know if you have updates!
I'm really confused about the 3.17.3 bit..
The module should work with older Nuxt versions, we need to ensure a minimal nuxt version: when we'll update nuxt here to 3.16.0, anyone using older version will also need to update nuxt to at least 3.16.0.
Since we've Nuxt 3.17.3 released, we want also use this latest version here in the playground, to do that we need to move nuxt to devDependencies using ^3.16.0 and use @nuxt/kit in dependencies also with version ^3.16.0 and then use resolutions to override Nuxt version to 3.17.3 to allow run that version with the tests and the playground.
For consumers, the minimal Nuxt version will be the @nuxt/kit at dependencies (we don't need Nuxt as dependency, we need Nuxt as dev dependency, the playground will use the version we've in the resolutions, in the playground it doesn't matter the Nuxt version you configures)
This is the package.json at vuetify nuxt module, preparing 3.16.0 support: