Stub's slots not rendering when using mixed slot syntax with shallowMount

[kailniris]

Version

1.0.3

Reproduction link

https://codesandbox.io/s/vue-template-xyodj

Steps to reproduce

Shallow mount a component which root component has multiple slots and different slot syntax is used for them.

What is expected?

Properly renders the shallow mounted component's root's slots.

What is actually happening?

Does not renders the slots contents or renders "<template></template>".

---

It works if you mix the v-slot: syntax with the # syntax but if you mix the slot=" " syntax with any other the rendered html will be broken. It also works properly if you don't mix the syntax.
Actually, this is a problem because I use Vuetify and some why I can only use the deprecated slot=" " syntax.
example:

<VNavigationDrawer>  
  <template slot="prepend">
    renders
  </template>

  <span>default slot content</span>
</VNavigationDrawer>

<VNavigationDrawer>  
  <template v-slot:prepend>
    does not renders
  </template>

  <span>default slot content</span>
</VNavigationDrawer>

edit:
The default slot considered as slot=" " syntax in this case so for my Vuetify example the default slot causes the issue. I edited the examples according to this.

workaround:

<VNavigationDrawer>  
  <template v-slot:prepend>
    renders
  </template>

  <template v-slot:default>
    <span>default slot content</span>
  </template>
</VNavigationDrawer>

[dobromir-hristov]

So as you can expect, mixing the slot syntax may cause issues. If you like us to help, create an example that we can actually run and assert on. The attached link doesnt really help much.

But as a general advice, when mixing slot names, I advice you to specify the default one as well, makes things much more readable :)

[kailniris]

Mixing slot syntax has no real use so the case its not working is not an issue. The problem is v-slot: and hash syntax do not work with default slot if no <template v-slot:default> is provided.
I agree explicitly providing the default slot is a good practice. A warning in the documentation explaining this case would be enough I think. I can create a PR in the docs for this case.
What do you think?