This should reduce the flakiness and issue with finding open DevTools
tabs for the corresponding pages.
Currently we do multiple loops over all the targets, so this should have
a nice performance improvement when multiple pages are opened.
With a fallback for older versions.
This should reduce the flakiness and issue with finding open DevTools
tabs for the corresponding pages.
Currently we do multiple loops over all the targets, so this should have
a nice performance improvement when multiple pages are opened.
This PR implements formatting for `SymbolizedError` objects that are
part of "resolved arguments". A follow-up PR will handle the actual
conversion of `Error` remote objects to `SymbolizedError`s.
The "SymbolizedError" class represents a fully resolved error: The stack
trace is fully resolved and (in the future), the full `Error.cause`
chain is also fully resolved.
We'll use the `SymbolizedError` for both "uncaught exceptions" as well
as when logging `Error` objects to the console (e.g. `console.log(new
Error())`. This means the `resolvedArgs` array in `ConsoleFormatter`
will contain one `SymbolizedError` instance for every `Error` object
logged.
This is the stack trace of the console message itself. If the argument
is an Error object or an "Error.stack" like string we don't do anything
special (yet).
The stack trace is source mapped if source maps are available.
The function matches the target ID of the console message to the
`SDK.Target` of DevTools. The only oddity is that DevTools works in a
lazy manor: It creates stack traces upfront and as source maps come in,
stack traces get updated. This does not work for the MCP server.
Instead, we wait for script parsed events and source maps to attach
before creating the stack trace. Since this could take potentially a
while, we guard it with a time out.
build/src/third_party/devtools.js is only used during bundling, but we
publish it unnecessarily. We should remove it to not cause confusion and
slightly decrease package size.
Co-authored-by: Piotr Paulski <piotrpaulski@chromium.org>
The `devtools-formatter-worker` is a separate entrypoint from the MCP
entrypoint. It is identical to the upstream
`front_end/entrypoints/formatter_worker/formatter_worker-entrypoint.js`
and a required part to make source mapping, formatting and other
AST-based DevTools features work.
The implementation consists of 3 parts:
1) A trivial `devtools-formatter-worker.ts` file that imports the
DevTools entrypoint.
2) A new bundle output, bundling everything that needs to run in the
worker.
3) A call that initializes the `FormatterWorkerPool` with the custom
entrypoint. Otherwise we'd use the unbundled entrypoint from
`chrome-devtools-frontend` not available to us at runtime.
Note that we could improve code splitting in the future as some things
like `core/common` are now bundled twice.
---------
Co-authored-by: Alex Rudenko <OrKoN@users.noreply.github.com>
A follow-up PR will add a single instance of the `UniverseManager` to
`McpContext` similarly to the *Collectors. We don't do that in this PR
yet, as we need to wait for some chrome-devtools-frontend changes to
roll.
This PR suppresses all the CDP command errors that DevTools logs via
`console.error`. (mostly `Storage.getStorageKey` errors). These
`console.error`s could also break MCP client that don't ignore invalid
JSON on stdio.
Nikolay Vitkov