Cannot read properties of undefined (reading 'filter')

[mrleblanc101]

Environment

---

• Operating System: Darwin
• Node Version: v20.18.0
• Nuxt Version: 3.15.1
• CLI Version: 3.17.2
• Nitro Version: 2.10.4
• Package Manager: [email protected]
• Builder: -
• User Config: default
• Runtime Modules: floating-vue/nuxt, @nuxtjs/[email protected], @vueuse/[email protected], @pinia/[email protected], @nuxt/[email protected], @nuxt/[email protected], @nuxtjs/[email protected], @nuxtjs/[email protected]
• Build Modules: -

---

Reproduction

https://stackblitz.com/edit/github-9ytrzgtu?file=pages%2Findex.vue

Describe the bug

As soon as I add an i18n custom block to my component, the app crash with this error:

Cannot read properties of undefined (reading 'filter')

The code for the language switcher comes from the documentation (except the console.log):

<script lang="ts" setup>
const { locale, locales, t } = useI18n();
const switchLocalePath = useSwitchLocalePath();

const availableLocales = computed(() => {
    console.log(locales, locales.value);
    return locales.value.filter((i) => i.code !== locale.value);
});
</script>

I notice that locales is sometime a ComputedRef and sometime a Reactive.

Where there is a <i18n> custom block:

When there isn't one:

That would explain why the locales.value.filter since a Reactive doesn't need a .value

Additional context

No response

Logs

[mrleblanc101]

I think I understand my error, but it's not explained at all in the Nuxt-i18n documentation why there is sometime a useScope: 'local' in the useI18n() call.

I changed my code for this:

const { locale, locales } = useI18n({ useScope: 'global' });
const { t } = useI18n({ useScope: 'local' });

Now I don't have the error:

Cannot read properties of undefined (reading 'filter')

Feel free to close if there is no change needed to the documentation.

[BobbieGoede]

Thank you for reporting, I think I know what the source of this behavior, I ran into it (or something similar) during recent refactors but preserved the original behavior as I wasn't sure if it was intended either.

I'm going to check if I can keep the behavior the same regardless of the presence of <i18n> block or local scope usage 🙏.