Pine To Typescript Port

Porting Pine Script to TypeScript

Pine Script is TradingView's bar-by-bar series DSL. It has powerful primitives (anchor-reset, request.security(), plot() overloads, color helpers like color.new()) that compile to TradingView's renderer. When porting a Pine indicator to a custom TypeScript app — typically with lightweight-charts as the renderer — naive translation produces "looks like Pine but is wrong" output. The semantics need to be ported, not just the syntax.

This skill catalogs the non-obvious concept mappings learned while porting an Anchored-VWAP / Level indicator (with std-dev bands, mitigation lines, zone boxes, and per-anchor labels).

When to use

Reach for this skill if you're:

• Porting any Pine indicator to TypeScript (or any non-Pine renderer)
• Implementing "Anchored VWAP" / "Level" / "Session VWAP" / similar
• Trying to match a Pine indicator's output pixel-for-pixel
• Confused why your TS port "looks 90% right but X is wrong"

The pattern — concept-by-concept mapping

1. Bar series + anchor-reset

Pine's signature trick: var float cum_pv = 0.0 with an if anchor_changed : cum_pv := 0.0 resets the cumulator at each anchor boundary (new day, new session, new week, etc.). Each anchor period builds its own VWAP from scratch.

In TS: walk the bars once, detect anchor boundaries, reset cumulators. Use functions like localDayKey() to detect "this bar is in a different day from the previous" — relative to the right timezone.

function anchorKey(unixSeconds: number, anchor: AnchorTf, tz: string): string {
  // E.g. "D" → date key in NY-local; "W" → ISO week key; etc.
  // For CME futures, use a FUTURES_DAY_SHIFT to make the 18:00 ET
  // session boundary land on a calendar-day flip.
}

let cumPV = 0, cumV = 0, prevKey: string | null = null;
for (const bar of bars) {
  const key = anchorKey(bar.time, anchor, tz);
  if (key !== prevKey) { cumPV = 0; cumV = 0; }
  const typical = (bar.open + bar.high + bar.low + bar.close) / 4;  // ohlc4
  cumPV += typical * bar.volume;
  cumV += bar.volume;
  vwap[i] = cumPV / cumV;
  prevKey = key;
}

2. ohlc4 and other Pine source helpers

Pine has close, open, high, low, hl2, hlc3, ohlc4, volume. These map directly:

Anchored VWAP almost always uses ohlc4 as the typical price. If the Pine source says close, port it as close — don't "improve" it by switching to ohlc4.

3. Standard deviation bands

Pine's anchored-VWAP-with-bands indicators use a running variance:

Var = E[X²] − (E[X])²
    = cum_pv2 / cum_vol − vwap²

The trick is the second moment cumulator: cumPV2 += typical * typical * volume. Then sd = sqrt(cumPV2 / cumV - vwap*vwap) gives bands at vwap ± mult * sd. This is numerically more efficient than re-walking bars to compute variance.

4. plot() vs hline() vs custom series

Pine has multiple drawing primitives:

For indicators with MANY plot primitives per anchor (e.g. drawing ~60 segments per anchor), using one chart series per segment is slow. Roll them into a single ICustomSeriesPaneView that draws everything in one Canvas2D pass. See lightweight-charts-integration.

5. Color helpers

The transparency inversion is non-obvious. Pine's color.new(c, 85) means "85% transparent" → output alpha = 0.15. JS's typical rgba(..., 0.85) means "85% opaque" → output alpha = 0.85. Read the Pine source carefully; port to your withAlphaCss(color, 1 - pineTransp/100).

6. request.security() — higher-timeframe context

Pine's request.security(syminfo.tickerid, "D", close) fetches the daily close while running on a 5m chart. There's no direct TS equivalent — you need a separate data fetch for the higher TF, joined to your bars by time.

For an Anchored-VWAP that's anchored to daily/weekly anchors, you DON'T need request.security() — you can detect the anchor from the bar timestamps themselves (anchorKey(bar.time, "D", tz) returns a date key). Only reach for the dual-data-source pattern if the indicator computes something on the HTF and overlays on the LTF.

7. var vs regular assignment

Pine's var float cumulator = 0.0 declares a persistent-across-bars variable. Regular cumulator = 0.0 reassigns on every bar. In TS this is the difference between a let outside the loop (persistent) vs inside (per-iteration). Don't confuse the two.

8. na (not-available) handling

Pine has a first-class na value distinct from 0. TS doesn't. The right port is NaN for numeric "no value," and the chart-side renderer needs Number.isFinite() checks before drawing. See lightweight-charts-integration for the isWhitespace gotcha — DON'T strip NaN rows from data.bars; let the renderer skip them at draw time.

9. "Same code path in live + backtest + ML"

If your indicator runs in production, in backtests, and in ML feature pipelines, the same code path must produce the same numbers in all three. Don't fork — write the core computation once and call it from each context.

Workflow — the right port sequence

1. Read the Pine source. ALL OF IT. (See read-reference-source-first.)
   Use mcp__pinescript__pine_search / pine_reference / pine_examples if
   the source uses any unfamiliar built-ins.

2. Annotate the Pine. Comment in the TS port file naming the Pine
   lines you're translating from. Easier to verify line-by-line.

3. Translate the math. Start with the cumulator-reset loop and the
   value computations. Skip styling for now.

4. Translate the drawing. Map plot/hline/box.new/label.new to your
   renderer's primitives. Pick "one custom series per indicator
   instance" if drawing > ~10 primitives per bar.

5. Translate the styling. Colors, line widths, dash patterns, alpha
   conventions. Pine's transp=85 ≠ alpha=0.85.

6. Browser-verify against the Pine reference. Take a screenshot of
   the Pine indicator on TradingView. Take a screenshot of your TS
   port. Diff visually. ANY divergence is a bug to find.

Gotchas

• Color transparency inversion. Pine color.new(c, 85) = 15% opaque. Easy to miss.
• bar_index vs time. Pine's bar_index is the sequential bar number. Your TS chart probably uses time. Don't confuse them in width calculations.
• time() returns ms in Pine, but your bars probably use seconds. Watch for the 1000× factor.
• syminfo.session.regular semantics. Pine knows about RTH (regular trading hours) vs ETH (extended). If the indicator uses session filtering, you need a bar.in_rth flag (computed from the bar's NY-local time vs the symbol's RTH window) before you can port.
• Pine's stepped-line vs lightweight-charts. Pine's plot(..., style=plot.style_stepline) renders a step. lightweight-charts has no built-in step series; you draw it in a custom series.
• Don't over-engineer. Many Pine indicators have decorations (label boxes, info tables, alert conditions) that aren't core to the math. Implement the math first, ship a minimal renderer, add decorations iteratively.
• Mitigation / touched-state. Many Pine indicators track "has price touched this level since the anchor closed?" via a per-anchor flag. Port this state EXPLICITLY — don't let it emerge from re-walking the bars in the renderer.

Reference implementation

The mapping above was extracted while porting an Anchored-VWAP "Level" indicator (multi-anchor: 15m, 2H, D, W, M, Q) with std-dev bands, mitigation horizontal lines, zone boxes, and per-anchor text labels. The eventual TS shape:

• A pure anchored-vwap.ts module with computeAnchoredVwap(bars, settings) returning the value series + per-bar metadata (anchor-close flag, mitigation touch state)
• A level-custom-series.ts ICustomSeriesPaneView that consumes the metadata and draws everything in one Canvas2D pass (with isWhitespace returning false; Number.isFinite guards inside draw())
• A separate DOM overlay layer for the few primitives that don't fit in a canvas series (text labels positioned via timeToCoordinate)
• Parity tests against known Pine values for a handful of anchor windows

Related skills

• read-reference-source-first — read the Pine source FIRST. Multiple times. This is THE highest-leverage step.
• lightweight-charts-integration — the chart-side primitives (custom series, time domains, isWhitespace) the ported indicator targets
• cme-futures-time-buckets — if the indicator anchors to D/W/M, the bucket math has to respect futures sessions, not calendar boundaries
• browser-verify-ui-changes — the right verification for "does my port match the Pine?"