icraft - Moses Yebei

The Problem

Designing 3‑D architecture diagrams usually requires a graphics‑heavy UI and custom data pipelines. Teams often cobble together ad‑hoc WebGL code, ending up with fragile, un‑testable demos that are hard to embed in existing portals.

What This Does

iCraft ships a browser‑based editor plus ready‑made React and Vue demos that expose a thin API for controlling scene objects. Core UI lives in demos/react/index.tsx, which aggregates 19 component imports (e.g., addon, animation, camerabar, serverstatus). Each demo (e.g., demos/react/addon/index.tsx) renders a self‑contained scene and showcases a single feature. The Vue counterpart lives under demos/vue/src/. Documentation and example markdown files under docs/ and blog/ describe the public API and usage patterns.

How It Is Wired

Execution starts at a Vite entry point such as demos/react/oilrefinery/src/main.tsx. Vite (config in demos/react/oilrefinery/vite.config.ts) bundles the app and mounts the root component from demos/react/index.tsx.

demos/react/index.tsx imports 19 child modules – the most‑connected node in the import graph (instability = 1). It does no upstream imports, so changes here have the widest blast radius.
Each child demo (e.g., demos/react/addon/index.tsx, demos/react/serverstatus/StatusCard.tsx) imports shared helpers from demos/react/serverstatus/utils.ts or demos/react/refinery/utils.ts. The utilities are leaf nodes (instability ≈ 0), safe to modify.
The Vue demo follows a similar pattern: demos/vue/src/main.js loads App.vue, which composes HelloWorld.vue. No circular dependencies were detected.

Because the code base consists mainly of UI components, there is no database or external service interaction. The only side‑effects are DOM updates and loading of static assets (e.g., .iplayer files in public/). The import graph is shallow: the root index imports components, each component imports at most two utility modules, and those utilities import nothing else.

How To Use It

# clone the repo
git clone https://github.com/moses-y/icraft.git
cd icraft

# install React demo dependencies (lockfile missing – see Code Health)
cd demos/react/oilrefinery
npm install   # or pnpm install if preferred

# start the Vite dev server (script defined in package.json)
npm run dev   # typically launches http://localhost:5173

The Vue demo follows the same steps in demos/vue/. No environment variables or secret keys are required; all assets are bundled from the public/ folder.

Real‑World Use

A monitoring dashboard can embed the iCraft player component (player-react.README.md describes the Web component) and drive element states through the exposed API. For example, a backend service posts JSON to a WebSocket that the player listens to, updating server status colors in real time without a page reload.

Code Health & Issues

High – Duplicated code blocks – 139 repeated 6‑line fragments across 18 demo files (e.g., demos/react/addon/index.tsx, demos/react/locale/index.tsx).
High – No test suite – 36 source files, 0 test files.
High – Missing lockfile – demos/react/oilrefinery/package.json has no package-lock.json/pnpm-lock.yaml.
High – No CI pipeline – repository lacks .github/workflows or other CI config.
Medium – No Dependabot/Renovate – manifests present but no auto‑update bot.
Medium – Large binaries in repo – public/videos/iCraftEditor.mov (65 MB) and several > 60 MB .gif/.iplayer assets.
Low – Missing repo conventions – no .editorconfig, .gitattributes, or formatter config.

All findings stem from deterministic static analysis; no additional issues are inferred.

The Bottom Line

iCraft provides a functional collection of React/Vue demos for 3‑D architecture visualization with clear component boundaries, but the code base suffers from duplicated UI logic, absent testing/CI, and unmanaged binary assets. It suits teams that need a quick visual prototype and are prepared to refactor the demos into a maintainable library. Adding tests, a lockfile, and CI will be essential before adopting it in a production pipeline.

What the analyser found

Deployment readiness

4/7

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

Composition

322 files

Markdown64
TSX25
JSON17
HTML7
TypeScript7
CSS4

ReactVue

Module dependencies

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

graph LR n0_react_serverstatus_interface["interface"] n1_mos_react_serverstatus_utils["utils"] n2_demos_react_refinery_types["types"] n3_mos_react_serverstatus_index["index"] n4_demos_react_refinery_index["index"] n5_eact_serverstatus_StatusCard["StatusCard"] n6_demos_react_ecommerce_index["index"] n7_demos_react_refinery_utils["utils"] n8_demos_react_tip1_index["index"] n9_demos_react_addon_index["index"] n4_demos_react_refinery_index --> n7_demos_react_refinery_utils n4_demos_react_refinery_index --> n2_demos_react_refinery_types n7_demos_react_refinery_utils --> n2_demos_react_refinery_types n5_eact_serverstatus_StatusCard --> n0_react_serverstatus_interface n5_eact_serverstatus_StatusCard --> n1_mos_react_serverstatus_utils n3_mos_react_serverstatus_index --> n1_mos_react_serverstatus_utils n3_mos_react_serverstatus_index --> n0_react_serverstatus_interface n3_mos_react_serverstatus_index --> n5_eact_serverstatus_StatusCard n1_mos_react_serverstatus_utils --> n0_react_serverstatus_interface

Findings

MediumNo CI/CD pipeline detected - no automated build/test gate .github/ or CI config
LowDependencies declared without a lockfile - non-reproducible builds demos/react/oilrefinery/package.json

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.

high3

medium2

low1

Add a test suite; this repository has nonehigh36 occurrences

36 source files, no test files

Any change ships with no signal that existing behaviour still holds, so a regression reaches production undetected.

Fix: Add one test per public entry point, then a CI step that runs them.

Commit a lockfile beside the manifesthigh

demos/react/oilrefinery/package.json

manifest with no lockfile in scope

An unlocked range means the artifact you tested and the artifact you ship can contain different transitive code, so a malicious patch release reaches production with no diff.

Fix: Run the package manager once and commit the generated lockfile.

Add a workflow that builds and tests this repositoryhigh

34 source files, no CI configuration

Every change merges with nobody having run the build once, which across this estate is 499 repositories.

Fix: Add a workflow running the project build and test command on push and pull_request.

Enable Dependabot or Renovatemedium

2 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.

Move large binaries to Git LFS or out of the repositorymedium27 occurrences

public/videos/iCraftEditor.mov

27 blobs over 5MB: iCraftEditor.mov 65.3MB, car-animation.gif 60.2MB, NetworkArchitectureSpecial.iplayer 56.6MB

One repository here carries twenty blobs over 5MB including a 10.9MB spreadsheet, so every clone and every CI checkout pays for data nobody diffs.

Fix: Track those extensions with LFS, or move datasets to object storage and fetch them in a setup step.

Add the repository convention files this project lackslow3 occurrences

missing .editorconfig, .gitattributes, a formatter config

Without them one contributor's editor writes tabs into a Python file, a shell script commits with CRLF and fails in the container, and a notebook diff is unreviewable.

Fix: Add .editorconfig, .gitattributes with text=auto eol=lf, and a formatter config.

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.