Release v1.0.0

[harlan-zw]

Discussion for any feedback and/or questions related to v1 Release.

Full release notes are available as a post on my blog

[francoism90]

@harlan-zw Congrats! I'll check out the V1 changes later, I'm now simple use useTitle(..).

[harlan-zw]

Thanks :)

I'm guessing you're talking about useTitle from VueUse? If so, feel free to use useTagTitle now if you like the simpler composables, the only issue with the VueUse one is that doesn't support SSR

[smarlhens]

Hey, congrats for the step ahead !
I've tried migrating to V1 but I face the following error message in my unit test:

TypeError: Cannot read properties of undefined (reading '_sde')
 ❯ markSideEffect ../../node_modules/@unhead/vue/dist/chunks/index.cjs:64:13
 ❯ markEl ../../node_modules/@unhead/vue/dist/chunks/index.cjs:117:7
 ❯ renderTag ../../node_modules/@unhead/vue/dist/chunks/index.cjs:123:7
 ❯ renderDOMHead ../../node_modules/@unhead/vue/dist/chunks/index.cjs:148:21
 ❯ runNextTicks node:internal/process/task_queues:61:5
 ❯ listOnTimeout node:internal/timers:528:9
 ❯ processTimers node:internal/timers:502:7

I'm only using useHeadfor title and meta so I can stay for now on v0.9.x and I haven't to the time to make a reproduction repo :/
I will do it in the next few days if I find the time.

[harlan-zw]

Thanks! I'm not exactly sure what is causing the issue, but I've pushed up a release (v1.0.11) that may solve it.

If not, whenever you have a chance for a reproduction repo it would be appreciated 🙏

[smarlhens]

It seems I don't have the problem anymore using the latest version (v1.0.16), thanks!

[vetruvet]

@harlan-zw congrats on the stable release! With pretty much the whole core being in unhead, is there any compelling reason to use this lib (other than the Head component) instead of just using unhead directly? (assuming the project is not already using this lib)
Or alternatively, are there any plans for features in this lib that will not be in unhead that would differentiate the two?

[harlan-zw]

Thanks @vetruvet

I'd actually recommend just using @unhead/vue directly if you can, as you'll get better tree-shaking and a smaller bundle.

Another reason to use @vueuse/head would be if you have any dependencies which rely on it (such as Vuetify).

See https://unhead.harlanzw.com/integrations/vue/vueuse-head

This package will continue to exist as a thin wrapper, all features will land in unhead directly (unless component related).

[camsteffen]

@harlan-zw Why not deprecate @vueuse/head then?

[harlan-zw]

• It would break ecosystem dependents
• Unhead doesn't export components
• More work for little benefit