feat: support Vue3

[farnabaz]

Refactor module and use @vue/compiler-sfc instead of vue-docgen-api and start supporting Vue 3.

TODO

• Extract prop types, defaults and requirement.
• handle regular scripts

Here is the current result of meta extractor:

[                                                                                                               
  {
    "name": "Test",
    "props": [
      {
        "name": "hello",
        "default": "?",
        "type": "?",
        "required": "?",
        "values": "?",
        "description": "?"
      }
    ],
    "slots": [
      "default",
      "nuxt"
    ]
  },
  {
    "name": "NuxtWelcome",
    "props": [
      {
        "name": "appName",
        "default": "?",
        "type": "?",
        "required": "?",
        "values": "?",
        "description": "?"
      },
      {
        "name": "version",
        "default": "?",
        "type": "?",
        "required": "?",
        "values": "?",
        "description": "?"
      },
      {
        "name": "title",
        "default": "?",
        "type": "?",
        "required": "?",
        "values": "?",
        "description": "?"
      },
      {
        "name": "readDocs",
        "default": "?",
        "type": "?",
        "required": "?",
        "values": "?",
        "description": "?"
      },
      {
        "name": "followTwitter",
        "default": "?",
        "type": "?",
        "required": "?",
        "values": "?",
        "description": "?"
      },
      {
        "name": "starGitHub",
        "default": "?",
        "type": "?",
        "required": "?",
        "values": "?",
        "description": "?"
      }
    ],
    "slots": []
  },
  {
    "name": "NuxtLayout",
    "props": {},
    "slots": []
  },
  {
    "name": "NuxtErrorBoundary",
    "props": {},
    "slots": []
  },
  {
    "name": "ClientOnly",
    "props": {},
    "slots": []
  },
  {
    "name": "NuxtLink",
    "props": {},
    "slots": []
  }
]

[farnabaz]

\cc @pi0 @atinux

[atinux]

Can we merge this one (nice refactor so far) into a dev branch for the new version focused on Nuxt 3?

Then creating the issues to keep track of the missing pieces.

[farnabaz]

components:extend runs after nitro generations and we can't inject runtimeConfig inside this hook.
addTemplate does not work either. Calling addTemplate inside components:extend does not work.

@pi0 @danielroe is there any possible solutions?

---

As I checked, nitro:config also runs before component:extend

[atinux]

What about using the storage to transfer informations to the API endpoint instead of runtimeConfig @farnabaz ?

[pi0]

Persisting indeed seems better idea than runtimeConfig. For either (or my next suggestion), you have to directly modify nitro.options by accessing nitro instance via nitro:init

Nitro has a new feature called virtual. You can use it to provide virtual for using in API route.

[farnabaz]

So what you are suggesting is to create a cache file and add it to serverAssets. Will try this one 👍

I don't think we can create virtual Apis, since we have components after nitro initialization.
I put logs on different hooks and here is the order:

nitro:config
nitro:init
components:extend 

[pi0]

I don't think we can create virtual Apis, since we have components after nitro initialization.

That's fine. Nitro is only initialized but actual build happens after nuxt build :) nitro:init is to only grab it's instance and build happens on build:done (https://github.com/nuxt/framework/blob/83d27bd158f6b0d9f2b776a47dbac4c68dc653fa/packages/nuxt3/src/core/nitro.ts#L149)

[atinux]

Awesome 🚀