Ideas / Todos

[antfu]

• Resize frame / pop-out as standalone webpage
• Calling CLI scafolding tools (await @pi0)
• In app editor (Monaco + Volar), with seperated script / template / style (cc @Atinux)
• Inspector of the elements in webpage
• Routes info
• Pages tree (with one click to navigate, etc)
• Tests?
• Modules contributed view, e.g. Tailwind module for design system preview, etc.

(feel free to add your ideas or discuss below!)

[danielroe]

• Timings/performance info
• Nuxt hooks timeline (when/what)
• Enable/attach browser debugger with a click

[pi0]

In app editor (Monaco + Volar), with seperated script / template / style (cc @Atinux)

I believe this is probably out of the scope of devtools. We are not making an editor but an extension for the editor. Such thing could, later on, be in a separate project such as Nuxt Admin for a web-based editor and integrate devtools.

[Atinux]

I wanted to explore the feeling of it 😊 , agree that it could live in admin, but such implementation is quite easy to do.

[pi0]

Sure we can experience it with admin :) It is easy but not really what I would imagine to include for devtools. We might have (readonly) editor for virtual files tough in UI since it later needs to be supported for VSCode integration as well.

[pi0]

Related issues about timing and performance:

• hook events unjs/hookable#37
• debug hooks nuxt#13509
• server lifecycle timing unjs/nitro#86

[Atinux]

Also, regarding the VFS, i see you supported unjs/nitro#173

How can we access this VFS to list the files in the devtools @pi0 ?

[pi0]

How can we access this VFS to list the files in the devtools @pi0 ?

We have two options: Expose a rest API from nitro vfs or since we are already planning to implement external module integrations, maybe we can simply embed the Nitro /_vfs endpoint in an iframe and improve UI in one place. There are also unjs/nitro#3 and unjs/nitro#4 this way we can easily extend dev tools and progress in parallel to add more dev tools components.

[Atinux]

Well I guess it would be nice if /_vfs could support Accept: application/json or even /_vfs.json directly, then no iframe needed directly 😊

[pi0]

Well I guess it would be nice if /_vfs could support Accept: application/json or even /_vfs.json directly, then no iframe needed directly 😊

We can support an explicit endpoint too but do you consider there are other UI parts being introduced by nitro such as swagger UI? Extendability of devtools is unavoidable we cannot add all modules to the devtools and there is already an undergoing feature in nitro same for modules such as tailwind. If IFrame has limitations, probably it is time to consider that. The point is to decentralize.

[Atinux]

I won't compare both Nitro and Nuxt modules since Nitro is part of Nuxt core and listing the VFS is same as showing the .nuxt in Nuxt 2 (without the advantage of updating them for debugging).

But if you want to make a "Nitro" tab in the devtools that make an iframe of /_nitro which both have VFS and Swagger API, I am fine with this too. We will just waste energy to start with into two different projects for working on UI.

[pi0]

Nitro, same as Vite is an underlying framework Nuxt is using not part of the core. We are simply leveraging a shared VFS context to be in a single layer otherwise, indeed had to have two VFSs.

/_vfs UI is already implemented and exposed from nitro it is only a matter of integrating it as an iframe. We can add sidebar and UI improvements of course without double efforts :) And it is not a waste of energy to think of stable tooling to provide module authors making their extensions for UI consistent with Devtools. We have @nuxt/ui specifically for this reason. It can be used for Nitro UIs as well.

As mentioned, we will have many of these cases such as Vitest UI in the future that can be easily integrated into devtools with an iframe and communicate with messaging. As for POC, Nitro already provides the UI and can be integrated inside the Devtools and this method of integration is consistent with what is planned for extendability.

I think fact of having a generic code editor is making it confusing to make a decision. VFS UI is not same as the admin feature we are thinking of but can definitely benefit from a shared codebase (@nuxt/ui) for consistency and common elements such as a file-tree.

[antfu]

If we are going to embed iframe for each integration (like Nitro UI, Vitest UI, and ones from modules), I guess it also makes sense to have the code editor as an optional module that contributes a view, so it would be decoupled from our devtools, while could be quite powerful(imagine we ship the entire Web VS Code to it) for those who find it useful?

[pi0]

Surely. We can explore it as an external module for the code editor 👍🏼 (BTW vfs, while is exposed from Nitro, can probably be called "Virtual Files" as it aggregates all of them including for Nuxt. It is kinda an exceptional part. Rest of Nitro can be referred to Nitro or Server such as "Server Routes")

[Atinux]

Submitted by @danielroe on Discord:

https://twitter.com/julien_rpt/status/1545733239117168640

[antfu]

Since most of them here are implemented or have a basic version, close in favor of #20