Vscode: Custom Object Formatter for debugger

[octref]

Wondering if it's possible to have Custom Object Formatter for debugger, since v8 inspector protocol now supports that.

Chrome DevTools now has it: https://medium.com/@paul_irish/debugging-node-js-nightlies-with-chrome-devtools-7c4a1b95ae27

@roblourens

[roblourens]

Yeah I've seen that, but it doesn't seem to have gotten a lot of traction. And might be an awkward fit into the vscode way of doing things.

[isidorn]

Let's keep this open as a feature request

[ntucker]

This is pretty essential to working with immutablejs: https://github.com/andrewdavey/immutable-devtools

[muj-beg]

Also would be useful for working with MobX: https://github.com/motion/mobx-formatters

[livemixlove]

Investigating this. Looks like this is where the action happens:

https://github.com/Microsoft/vscode-chrome-debug-core/blob/master/src/chrome/chromeDebugAdapter.ts#L2710

https://github.com/Microsoft/vscode-chrome-debug-core/blob/master/src/chrome/chromeDebugAdapter.ts#L2672

Edit: this probably should happen in the vscode-chrome-debug repo

[livemixlove]

Then here is the code for immutable formatters:
https://github.com/andrewdavey/immutable-devtools/blob/master/src/createFormatters.js

[lppedd]

Also useful for https://github.com/emmanueltouzery/prelude-ts

[ChuckJonas]

• one this.... Would be helpful with debugging javascript proxy.

Example Formatter

[ELLIOTTCABLE]

Adding another use-case: BuckleScript, compiling OCaml to JavaScript. The internal representation of runtime values is very OCaml-specific; but they have a Chrome formatter to aid debugging in Chrome.

It'd be really nice to be able to actually use VScode for debugging BuckleScript projects. /=

[weinand]

Related items are:

• https://github.com/microsoft/vscode/issues/46829
• https://github.com/Microsoft/vscode-java-debug/issues/236

[weinand]

I've investigated Custom Object Formatters (aka COF or Human Readable Objects) across different language environments/runtimes and here are the results:

• Chrome Dev Tools (Custom Object Formatters):
  
  
  
  • How: hooks into UI via JsonML
  
  
  • Where used: console, Watches/Scopes (variables), Hovers
  
  
  • API:
    
    class Formatter { header(object: object, config): JsonML; hasBody(object, config): boolean; body(object, config): JsonML; } // ... window.devtoolsFormatters= [ new Formatter() ]
  
  
• Python:
  
  
  
  • How: "repl" method returns printable representation (string)
  
  
  • Where used: for string based output (console, REPL)
  
  
  • API: add repr(object) method on class
  
  
• Java (Eclipse):
  
  
  
  • How: a method that returns a printable representation (string)
  
  
  • Where used: for string based output (console)
  
  
  • API: add toString() method or separate "Detail Formatter" class
  
  
• C# (VS DebuggerDisplay):
  
  
  
  • How: declarative format spec (proprietary)
  
  
  • Where used: variables view
  
  
  • API: [DebuggerDisplay("...”)] annotation syntax at the top of a class
  
  
• C++ (VS natvis)
  
  
  
  • How: XML-based declarative format spec.
  
  
  • Where used: variables view
  
  
  • API: XML file installed in known location
  
  

Custom Object Formatters in generic debuggers:

• LLDB (https://lldb.llvm.org/use/variable.html)
  
  
  
  • How: Python scripts for "filters" or "children providers"
  
  
  • Where used: command interpreter when displaying variables
  
  
  • API: Python classes
  
  

For VS Code the fundamental question is:
can Custom Object Formatting be implemented generically on the VS Code side based on DAP, or is it done inside Debug Extensions (i.e. the Debug Adapter)?

IMO the answer is "no": COF needs to be done in debug extensions. Here is why:

• COFs are runtime/debugger specific,
• concrete formatters cannot be shared across languages because they depend on access to the underlying object representation (which is debugger/runtime specific),
• formatters need to be "close" to the debugger/runtime so that they can determine the low-level type of objects.

The verdict:
We will not provide COF generically but instead rely on debug extensions/debug adapters to support COF (ideally based on a native COF mechanism).
DAP already provides mechanisms to send hierarchical structures to the debug console, the variables and watches views, and value hovers. These mechanisms can be easily used to support those COF implementations from above that actually support hierarchies (Chrome Dev Tools, C#, C++, LLDB).

I recommend that we add support for the Chrome DevTools COFs to the "Debugger for Chrome". I will create a corresponding feature request.

[vscodebot[bot]]

This issue is being closed to keep the number of issues in our inbox on a manageable level, we are closing issues that are not going to be addressed in the foreseeable future: We look at the number of votes the issue has received and the number of duplicate issues filed. More details here. If you disagree and feel that this issue is crucial: We are happy to listen and to reconsider.

If you wonder what we are up to, please see our roadmap and issue reporting guidelines.

Thanks for your understanding and happy coding!

[justingrant]

Hi @weinand - I'm having trouble following the issue chain for this use case. #46829 (which was JS-specific) was closed in favor of this issue which is more generic. But this issue punts the ball back to each language's debugger. Is there a new issue to replace #46829 for the JS debugger?

I'm asking because I'm part of the team that's working on the polyfill for the soon-to-be-Stage3 JS Temporal proposal and we'd like a good way to show a text representation of Temporal objects in the VSCode debugger. My understanding of Chrome's Custom Object Formatters is that they need to be installed on the debugging-console side and opted into by every user, as opposed to letting library authors to control their own objects' string representation in the debugger. The latter is what we are looking for.

[weinand]

@justingrant yes, you are right: our investigation in this issue showed that Custom Object Formatters need to be implemented by individual debug extensions, but consequently we should reopen #46829 .