vuejs / vuejs/devtools

Devtools Kit

Open
#71 1 comment 16 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
TypeScript
Stars
2.9k
Forks
279
PR merge metrics
No merged PRs in 30d

Description

✏️ This is a draft note about a unified set of standard APIs to create devtools. I discussed about this a bit with @antfu too and trying to write down some ideas about it.

The idea is to standardize things to be able to :

  • One one side create shells to host dev tools

    • Various types of shell:
      • browser extension
      • embedded pane
      • standalone app
      • multi-devtools app
    • Implementation is not standardized, but following the standard would make any shell compatible with the applets
  • On the other side create devtools applets/plugins to implement various tooling and development features

    • We would have standard APIs to write logic that could be executed in various contexts:
      • Devtools UI
      • In the page
      • Vite plugin
      • Node process
      • ...
    • Provide standard APIs to communicate seamlessly no matter which context we are in
    • Standard manifest and APIs to expose functionality to the shell, for example:
      • Tabs/Launchers: title, icon, notification...
      • Settings
      • Search results/Command palette
      • Keyboard shortcuts
      • ...

Use cases

Then creating the equivalent of the current Nuxt devtools would be to pick a "embedded pane" shell and add various applets like "pages", "routing", "auto-imports"... For Vue devtools, it would be different set of applets.

Then we could put all of those applets into a "standalone app" shell and it would still work because communication between "Devtools UI" and "In the page" contexts are abstracted away.

A multi-devtools app like guijs could also implement this standard and have working vue components tree directly inside it. New applets ideas coming from it could be installing packages, killing ports, etc.

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

No files, tests, or implementation entry points are named. Start by reviewing the proposed shell and applet contexts and the discussion with @antfu, then define the standard API scope and acceptance criteria before implementation; done would be an agreed design rather than a small isolated change.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
devtools
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
15/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.