graphic walker - Moses Yebei

The Problem

Teams that need embedded visual analytics face a binary: build charting from scratch or bolt a heavy BI platform into their app. Graphic Walker targets that gap with a React component that provides Tableau-style drag-and-drop exploration without the infrastructure overhead.

What This Does

Graphic Walker is a React-based visual analytics library. Users upload CSV/JSON data, define dimensions and measures, then drag fields onto visual channels to build charts. It includes a data explainer for pattern analysis, spatial visualization via the leafletRenderer components, and a natural language query interface in components/askViz.

The main package lives in packages/graphic-walker, with a companion packages/duckdb-wasm-computation that handles client-side query computation via web workers. The repo is a fork of Kanaries/graphic-walker (3218 stars upstream), so it inherits a mature codebase with 25 test files and GitHub Actions CI.

How It Is Wired

Execution starts in packages/graphic-walker/src/index.tsx, which mounts App.tsx. The App component wires together the field system (fields/fieldsContext.tsx), the data source layer (dataSource/index.tsx), and the store (store/index.tsx). The Renderer.tsx component is the visualization output path, translating the visual spec into rendered charts.

The dependency graph shows 298 internal modules with 798 import edges. The src/interfaces module is the critical hub: 113 modules import it, making it the highest-blast-radius file in the repo. It's also part of a circular dependency cycle along with src/utils/index.ts and src/config.ts. The src/store/index module has 38 dependents and sits at the center of state management.

The computation path routes through src/computation/index.ts (934 lines, flagged as oversized), which delegates to either client-side workers or a remote query service. The src/App component imports 39 modules, making it the widest entry point into the system.

How To Use It

# Clone and install
git clone https://github.com/moses-y/graphic-walker
cd graphic-walker
yarn install

# Run the dev server
yarn dev

The package is published on npm as @kanaries/graphic-walker. To embed it, import the GraphicWalker component and pass a data source. No environment variables are required; the default configuration uses in-browser computation.

Real-World Use

A typical integration is a data analysis dashboard where users upload a CSV, explore it visually, and export findings. The component accepts a dataSource prop, so you can feed it parsed data from your backend. The DuckDB WASM package lets you offload computation to web workers, keeping the UI responsive on large datasets.

Code Health & Issues

Static analysis found 171 findings across 4 categories: 96 high, 74 medium, 1 low. The main issues:

High - Import cycles: src/interfaces.ts, src/utils/index.ts, src/config.ts participate in circular dependencies. This makes changes ripple unpredictably and complicates module loading.
High - Hub modules: src/interfaces.ts has 113 dependents; src/utils/index.ts has 39. Any change here has a wide blast radius.
Medium - Oversized files: src/interfaces.ts (934 lines) and src/computation/index.ts are hard to reason about in one pass.
High - Deep nesting: 31 files exceed 10 levels of indentation, notably fields/fieldsContext.tsx and utils/workflow.ts.

The CI audit found 2 high-severity issues: GitHub Actions pinned to mutable tags (peter-evans/create-pull-request@v3) and workflows that never invoke the test suite despite 18 test files existing.

The Bottom Line

This is a solid, feature-complete embedded analytics library with real-world adoption via the upstream project. The architecture is sound but the circular dependencies and hub modules will make significant refactoring painful. Teams needing a Tableau-like component in a React app should evaluate it; the CI gaps are worth fixing before relying on the green check.

What the analyser found

Deployment readiness

6/7

Container image
CI pipeline
Lockfile committed
Test suite
README
License
No committed secrets

Composition

346 files

TSX178
TypeScript112
JSON16
JavaScript7
CSS6
Markdown5

ReactTailwind

Module dependencies

The 10 most depended-upon modules of 298, from static import analysis. Red outline marks a module in an import cycle.

graph LR n0_raphic_walker_src_interfaces["interfaces"] n1_aphic_walker_src_utils_index["index"] n2_aphic_walker_src_store_index["index"] n3_graphic_walker_src_constants["constants"] n4_es_graphic_walker_src_config["config"] n5_ker_src_components_ui_button["button"] n6_playground_src_examples_util["util"] n7_yground_src_examples_context["context"] n8_ker_src_fields_fieldsContext["fieldsContext"] n9_mples_components_examplePage["examplePage"] n4_es_graphic_walker_src_config --> n0_raphic_walker_src_interfaces n8_ker_src_fields_fieldsContext --> n0_raphic_walker_src_interfaces n8_ker_src_fields_fieldsContext --> n2_aphic_walker_src_store_index n0_raphic_walker_src_interfaces --> n3_graphic_walker_src_constants n2_aphic_walker_src_store_index --> n0_raphic_walker_src_interfaces n1_aphic_walker_src_utils_index --> n3_graphic_walker_src_constants n1_aphic_walker_src_utils_index --> n0_raphic_walker_src_interfaces classDef cyc stroke:#ef4444,stroke-width:2px; class n0_raphic_walker_src_interfaces,n1_aphic_walker_src_utils_index,n4_es_graphic_walker_src_config cyc;

What would stop me shipping this

Ranked by severity × confidence × production reach. Reach is the honest discriminator across a collection that is mostly other people's code: the same finding matters more in something that ships.

high2

medium5

low1

Pin third-party GitHub Actions to a commit SHAhigh

.github/workflows

peter-evans/create-pull-request@v3

A tag can be moved, so the action running with your token and secrets is whatever its owner last pushed; this is how tj-actions/changed-files leaked secrets from thousands of repos.

Fix: Replace each @vN with the 40-character commit SHA, keep # vN as a comment, and let Dependabot bump the SHAs.

Make CI invoke the test suite it hashigh18 occurrences

.github/workflows

18 test files, no test command in any workflow

A green check that never executed an assertion is worse than no check, because reviewers trust it.

Fix: Add a test step to the existing workflow rather than a new workflow.

Declare least-privilege permissions for GITHUB_TOKENmedium4 occurrences

.github/workflows/auto-build.yml

4 workflow(s) declare no permissions, 2 of them reference secrets

With no declaration the token inherits the repository default, so any injected step can push commits or mint releases from inside your own CI.

Fix: Add permissions: contents: read at the top of the workflow and widen per job only where needed.

Enable Dependabot or Renovatemedium

4 manifest(s), no update bot configured

Without a bot a published advisory sits unpatched until someone audits by hand, which across 1,322 repositories means never.

Fix: Commit .github/dependabot.yml covering the repo ecosystems plus github-actions.

Install from the lockfile in CImedium

.github/workflows

yarn install without --immutable

A fresh resolution in CI means the tested dependency set is not the locked one, so the failure only appears after merge.

Fix: Use npm ci, yarn install --immutable, or pnpm install --frozen-lockfile.

Gate pull requests on a dependency vulnerability scanmedium

.github/workflows

no dependency scan in CI

This is the one gate that would catch a known-vulnerable package before it reaches a build, and no repository in the sample had it.

Fix: Add dependency-review-action on pull_request, or osv-scanner on push and a schedule.

Set persist-credentials: false on checkoutmedium

.github/workflows/auto-build.yml

checkout keeps the token, then dependencies are installed

The token stays in .git/config for every later step, so a malicious postinstall script reads a pushable credential without one ever being passed to it.

Fix: Add with: persist-credentials: false, and pass an explicit token only to the step that pushes.

Set timeout-minutes on the workflow jobslow4 occurrences

.github/workflows/auto-build.yml

4 workflow(s) declare no job timeout

A wedged step runs to the six-hour platform default, which on a two-hourly schedule means three runs overlap behind it.

Fix: Add timeout-minutes with a realistic bound to each job.

Checked deterministically against the repository tree and a bounded set of its files: committed credentials, unpinned actions and base images, missing lockfiles and update bots, workflows that discard failures, published advisories against the declared dependencies, runtime configuration, licensing and notebook reproducibility. No language model is involved in this section.