blink-devtools-docs icon indicating copy to clipboard operation
blink-devtools-docs copied to clipboard

DevTools modules & internal extensions overview

Open paulirish opened this issue 10 years ago • 1 comments

Captured these notes recently.. Dumping them here until we find a better place.

devtools modules overview

  • common - common utils
  • ui - common ui

you can build the devtools shell with just those 2

  • sdks is just a wrapper around protocol. wraps JSON around messages. key things like script, breakpoints, console messages. theoretically SDK can be reused by IDEs. web storm can grab the sdk and use it for debugging
  • if you get common/ui/workspace, you get basically an IDE. not related to chrome.
  • bindings: binds workspace & sdk. source mappings, how scripts map to UI scope. where you set the breakpoint when clicking in UI scope.

rest of modules are assorted. they all dependon on eachother. handful that are fused toeghet and served together as devtools loads. (ui & components.) dont want to load instantly everything, so some parts are lazy. not a good way to load files on demand. prefer modules as the lazy group.

  • accessibilty: a11y sidebar
  • acorn: js parser for prettyprint
  • audits: that panel
  • cm: codemirror
  • components : ui components that are SDK aware. breakpoints, object popover etc
  • console: console
  • emulation: device mode and emulation stuff
  • extensions duh
  • host: what the frontend needs from the embedder. e.g. we can index filesystem and get files.
  • layers: panel
  • main: app that binds things together
  • platform: OS dependent thing
  • profiler: cpu profiler
  • promises: promises pane
  • workers: eitehr formatting or persisted snapshots
  • sourceframe: cm wrapper with api we use
  • toolbox: part of responsive design mode, on top of inspected page. (where you choose your device)

core: ui, sdk, workspace, and maybe components.

internal extensions

runtime or console/module.json

very lean DI - declare capabilities and provide them.

defined mostly in Runtime.js.

Our code is a bunch of modules. It's a descriptor and a JS file. JS is deployed lazily when its required. Descriptor is captured here as declarative as extension.

  • PanelFactory: It's a panel factory that creates panels. It wants to be the last tab in the list.
    • ui/panel.js : self.runtime.extensions(WebInspector.PanelFactor) ... for each of them, do something. it hasnt yet loaded or instantiated.

language service example

language can sit a sibling to bindings layer.

language service that extension server depends on could expose an API for registering providers. if it finds an extension API that provides one, it'd use that. otherwise it'd query internal extensions for that.

query all extensions that provide language service. store them for future use in a map for mimetype. so it can instantiate later.

e.g. for the language service you want a declaration that says: "i'm the language service. i'm this mime type. i support this class."

paulirish avatar Sep 08 '15 17:09 paulirish

This is a good write up. Konrad and I were looking at the internal extensions the other day and counted 177. Seemed like an interesting thing to document / discuss. Also perhaps on that subject I understand that JS is lazily loaded in Dev, but on prod I'd assume it's all bundled.

@paulirish I've recently been thinking it'd be nice to revisit this project now that I have more experience and tackle some more concepts. If I filed some PRs and tagged you would you mind doing a quick read through?

jasonLaster avatar Oct 17 '15 03:10 jasonLaster