Crate rolldown_devtools 

Rolldown tries to emit useful internal tracing data during build time, so that devtools can consume them to provide better debugging experience. This crate implements the mechanism to emit tracing data and some utilities to help with that.

Implementation Details

The mechanism is built on top of the tracing crate. There’re two main important concepts in the tracing crate:

• Spans: represent a period of time in the program execution. They can have fields associated with them.
• Events: represent a single point in time. They can also have fields associated with them

Mental model

The way how rolldown devtools tracing works is like

<BundlerSpan>
  <TransformCallSpan CONTEXT_transform_call_id=".." CONTEXT_plugin_name="..">
    {emitTransformStartEvent({ transform_call_id: '${transform_call_id}', plugin_name: '${plugin_name}' })}
    {runTransformCode()}
    {emitTransformEndEvent({ transform_call_id: '${transform_call_id}', plugin_name: '${plugin_name}' })}
  </TransformCallSpan>
</BundlerSpan>

Why?

• Spans allows us inject context data implicitly, so that we don’t need to pass them around manually.
• Spans could track the async context automatically, so that we don’t need to worry about losing context in async code.

Re-exports

pub use rolldown_devtools_action as action;

Macros

trace_action

trace_action_enabled

Structs

DebugTracer

Session

Functions

flush_session

Request the writer thread to drain and flush every file for session_id, returning a receiver that fires once the flush has completed. Consumers use this to establish a happens-before relationship between bundle.close() resolving and a reader opening the session’s log files.

generate_build_id

generate_session_id