-
-
Notifications
You must be signed in to change notification settings - Fork 232
feat(deps): use nuxt-og-image v6 #1118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
📝 WalkthroughWalkthroughThis pull request migrates from the Open Graph image API Possibly related PRs
🚥 Pre-merge checks | ✅ 1✅ Passed checks (1 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
🧪 Generate unit tests (beta)
Comment |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actionable comments posted: 6
| defineOgImage('Default', { | ||
| title: `~${username.value}`, | ||
| description: results.value ? `${results.value.total} packages` : 'npm user profile', | ||
| primaryColor: '#60a5fa', | ||
| }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: results.value is async, so OG description will likely always be 'npm user profile'.
results from useNpmSearch won't have resolved when defineOgImage is evaluated during SSR, so the ternary will always take the fallback branch. If showing the package count in the OG image was intentional, this is a regression from the previous function-wrapped approach. Otherwise, the fallback is perfectly sensible.
| defineOgImage('Default', { | ||
| title: `@${orgName.value}`, | ||
| description: packageCount.value ? `${packageCount.value} packages` : 'npm organization', | ||
| primaryColor: '#60a5fa', | ||
| }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🧩 Analysis chain
🌐 Web query:
nuxt-og-image v6 defineOgImage reactivity
💡 Result:
In nuxt-og-image v6, defineOgImage() should be treated as non-reactive by default: it sets the OG meta once at the time you call it (during setup / SSR). So if you pass values that change later on the client, crawlers won’t see those updates anyway (they only read the initial HTML), and your tags won’t update unless you call defineOgImage() again. [1]
Recommended pattern (SSR-safe)
Fetch/compute the data before calling defineOgImage() (e.g. await useAsyncData(...), then call it with the resolved values). This is also how the docs show it for Content-driven pages. [2]
If you truly need “reactivity” (client-side navigation)
Re-run it when inputs change:
const route = useRoute()
watchEffect(() => {
defineOgImage('NuxtSeo', {
title: route.meta.title ?? 'Default',
})
})When the options/props change, nuxt-og-image generates a different OG image URL (and caches by those inputs), so re-calling it with new values is the intended way to “update” the OG image definition. [3]
Sources: defineOgImage API docs [1], Nuxt Content integration example [2], caching/invalidation behavior [3].
[1] https://nuxtseo.com/docs/og-image/api/define-og-image
[2] https://nuxtseo.com/docs/og-image/integrations/content
[3] https://nuxtseo.com/docs/og-image/guides/cache
🏁 Script executed:
cat -n app/pages/org/[org].vue | head -60Repository: npmx-dev/npmx.dev
Length of output: 2030
🏁 Script executed:
sed -n '140,160p' app/pages/org/[org].vueRepository: npmx-dev/npmx.dev
Length of output: 853
🏁 Script executed:
grep -n "useOrgPackages" app/pages/org/[org].vueRepository: npmx-dev/npmx.dev
Length of output: 128
🏁 Script executed:
find . -name "*.ts" -o -name "*.js" -o -name "*.vue" | xargs grep -l "export.*useOrgPackages" | head -5Repository: npmx-dev/npmx.dev
Length of output: 100
🏁 Script executed:
cat -n app/composables/npm/useOrgPackages.tsRepository: npmx-dev/npmx.dev
Length of output: 6789
🏁 Script executed:
grep -n "emptySearchResponse" app/composables/npm/useNpmSearch.ts | head -5Repository: npmx-dev/npmx.dev
Length of output: 259
🏁 Script executed:
sed -n '47,53p' app/composables/npm/useNpmSearch.tsRepository: npmx-dev/npmx.dev
Length of output: 207
🏁 Script executed:
grep -n "defineOgImage\|watchEffect" app/pages/org/[org].vueRepository: npmx-dev/npmx.dev
Length of output: 91
The OG image description will always show 'npm organisation' instead of the actual package count.
useOrgPackages uses useLazyAsyncData, which does not block page setup and defaults to returning an empty emptySearchResponse (with objects: []). When defineOgImage is called during setup, packageCount.value will be 0, causing the ternary to always resolve to the fallback text.
According to the nuxt-og-image v6 documentation, defineOgImage() is non-reactive and should be called only after data is available. To fix this, either await the data before calling defineOgImage, or use watchEffect to re-call it once the lazy data resolves:
watchEffect(() => {
defineOgImage('Default', {
title: `@${orgName.value}`,
description: packageCount.value ? `${packageCount.value} packages` : 'npm organisation',
primaryColor: '#60a5fa',
})
})| defineOgImage('Default', { | ||
| title: `${pkg.value?.name ?? 'Package'} - Docs`, | ||
| description: pkg.value?.license ?? '', | ||
| primaryColor: '#60a5fa', | ||
| }) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same async-data concern as package-code/[...path].vue.
pkg.value is fetched asynchronously via usePackage, so title and description will resolve to their fallbacks ("Package - Docs" and "") if the data hasn't loaded when defineOgImage is evaluated. See the verification on the package-code file for the same pattern.
nuxt-modules/og-image#435