Devtools Kit
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
- Various types of shell:
-
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
- ...
- We would have standard APIs to write logic that could be executed in various contexts:
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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- 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