Using mapState with array syntax will override/alter types of the component

[johuhype]

Reproduction

see below

Steps to reproduce the bug

test.store.ts

import { defineStore } from "pinia";

interface TestState {
    unused: string;
    paraAdjusts: Array<string>;
    nextSerie: number;
}

export const useTrainingTestStore = defineStore('mod/training/test', {
    state: (): TestState => ({
        unused: '',
        paraAdjusts: [],
        nextSerie: null,
    })
});

myview.vue

<script lang="ts">
    import { defineComponent } from 'vue';
    import { mapState, mapActions } from 'pinia';

   export default defineComponent({
        data() {
            return {
                paraAdjusts: [] as Array<paraAdjust>,
            }
        },
        computed: {
            nextSerie(): MyClass {
                return this.nextSet;
            },
            ...mapState(useTrainingTestStore, ['unused']),
        },

Even tough paraAdjusts and nextSerie are not even getting mapped, their types in myview.vue will get altered:
-paraAdjusts will get Array<paraAdjust> & Array<string> instead of Array<paraAdjust>
-nextSerie will get number instead of MyClass

This can only be avoided if you use the object synatx for mapState:

mapState(useTrainingTestStore, {
    unused: 'unused'
}),

Expected behavior

Typescript types in components using mapState with array syntax should not be altered.

Actual behavior

Typescript types in components using mapState with array syntax are altered to the type defined in the used store.

Additional information

No response

[johuhype]

Additional information: Vue version is 2.7.10,
using the old export default Vue.extend({
instead of export default defineComponent({ also fixes the problem

[noook]

Using options API for both my components and my stores, Nuxt 3.3

For me, it seems that when using both mapState with array syntax and mapActions with array syntax, the second one will override in a way that makes Vue unhappy about the whole component's typipngs. However, when switch the mapActions to the object syntax, and by keeping the same names the errors seem to disappear.

I tried to reproduce on a different repository, without success. I'll post here again if I find a proof to this bug.