gr8r studio - Moses Yebei

The Problem

Teams need a lightweight, zero‑runtime‑dependency project‑management UI that can be deployed as a static site and can be customized without a heavy framework. The repo delivers a ready‑to‑run SPA that can be forked and tweaked for internal dashboards or as a demo for new clients.

What This Does

The application renders a project‑management workspace with a home dashboard, inbox, task lists, and multiple project‑view modes (board, list, table, calendar, timeline, files).

src/main.js pulls in src/styles/index.css and imports the routing and action modules.
src/shell/render.js builds the shell (sidebar, topbar, layout) and injects the current page or view.
src/pages/... modules export a function that returns an HTML string built from the global store (S).
src/views/... provide specialized renderers for board, calendar, etc.
src/actions/... modify S and trigger a re‑render via the event table A defined in src/actions/actions.js.
UI helpers in src/ui/ provide toasts, selects, and generic render functions.

The UI is built with plain ES modules and CSS; no React or Vue runtime is bundled. Icons are pulled from Lucide via the Vite virtual:icons plugin, so only used icons are bundled.

How It Is Wired

Entry point – index.html loads src/main.js.

main.js imports src/styles/index.css and then src/actions/actions.js.
actions/actions.js imports each actions/*.js module, each of which registers a handler on the shared action table A.
main.js also imports src/shell/render.js, src/shell/view-engine.js, and the page modules.
The router in view-engine.js listens to the URL hash and calls the appropriate page or view function.
The page/view returns an HTML string; render() injects it into the shell, then dispatches a rendered event.
actions/events.js attaches a delegated click handler to document.body; when an element with data-a="actionName" is clicked, A.actionName() executes, potentially updating the store and calling render() again.

Wiring hotspots –

src/actions/actions.js is the hub; most state changes flow through its table.
src/shell/render.js is the blast radius for UI changes; a single call rebuilds the whole DOM subtree.
src/core/store.js holds the immutable state; any function that mutates it (e.g., actions/teams.js) triggers a re‑render.

The graph is acyclic except for the action table’s self‑referencing A object, which is safe because handlers are pure functions.

How To Use It

Setup –

git clone https://github.com/moses-y/gr8r-studio
cd gr8r-studio
npm install

The .nvmrc pins Node 22, but the README accepts Node 18+.

Configuration – No environment variables needed; all data is in src/data/seed.js.

Running –

npm run dev      # http://localhost:5173, hot reload
npm run build    # dist/ production bundle
npm run preview  # serve the build locally

The build output is a static SPA; deploy dist/ to any static host or Vercel (via vercel.json).

Real‑World Use

A product‑manager can fork the repo, replace src/data/seed.js with their workspace JSON, and publish it on an internal portal. Because all logic lives in the browser, no API backend is required for a demo; switching to a real API would involve swapping out src/core/store.js and the action modules.

// Example: replace seed data
import { S } from './core/store.js';
S.projects = loadFromServer(); // fetch JSON, then re‑render

Code Health & Issues

Missing test suite – No __tests__ folder; all paths are untested.
No license – Repository lacks a LICENSE file; usage rights unclear.
CI – .github/workflows/ci.yml runs lint, format check, and a production build, but does not run tests.
Documentation – Only README.md and a screenshot; no API docs or component description.

These observations come from scanning the file tree and CI configuration; no static analysis run has been performed.

The Bottom Line

Gr8r Studio is a clean, framework‑free SPA that demonstrates a full project‑management UI in plain JavaScript. It is ideal for rapid internal demos or as a base for a custom static dashboard. However, the lack of tests, a license, and runtime support for server‑side data limits its use in production environments without further investment.

What the analyser found

Deployment readiness

4/7

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

Composition

86 files

JavaScript54
CSS18
JSON4
YAML1
Markdown1
HTML1

React

Module dependencies

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

graph LR n0_src_core_store["store"] n1_src_core_utils["utils"] n2_src_core_icons["icons"] n3_src_ui_helpers["helpers"] n4_src_core_constants["constants"] n5_src_shell_render["render"] n6_src_shell_view_engine["view-engine"] n7_src_components_task_list["task-list"] n8_src_actions_actions["actions"] n9_src_overlays_modals["modals"] n8_src_actions_actions --> n1_src_core_utils n8_src_actions_actions --> n4_src_core_constants n8_src_actions_actions --> n0_src_core_store n8_src_actions_actions --> n3_src_ui_helpers n8_src_actions_actions --> n5_src_shell_render n8_src_actions_actions --> n6_src_shell_view_engine n8_src_actions_actions --> n9_src_overlays_modals n7_src_components_task_list --> n1_src_core_utils n7_src_components_task_list --> n2_src_core_icons n7_src_components_task_list --> n4_src_core_constants n7_src_components_task_list --> n0_src_core_store n7_src_components_task_list --> n3_src_ui_helpers n7_src_components_task_list --> n5_src_shell_render n2_src_core_icons --> n1_src_core_utils n0_src_core_store --> n1_src_core_utils n0_src_core_store --> n4_src_core_constants n9_src_overlays_modals --> n1_src_core_utils n9_src_overlays_modals --> n2_src_core_icons classDef cyc stroke:#ef4444,stroke-width:2px; class n5_src_shell_render,n7_src_components_task_list,n8_src_actions_actions,n9_src_overlays_modals cyc;

Dependencies

5 of 6 declared dependencies are a major version behind. Resolved 6 of 6 against the registry.

Package	Declared	Latest	Behind
`globals`	^15.15.0	17.11.0	2 major
`vite`	^6.4.4	8.2.1	2 major
`@eslint/js`	^9.39.5	10.0.1	1 major
`eslint`	^9.39.5	10.8.1	1 major
`lucide`	^0.460.0	1.55.0	1 major

Findings

MediumNo test files detected - untested code paths repository-wide
MediumNo LICENSE file - unclear usage/redistribution rights root

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

medium4

low1

Add a LICENSE; redistribution rights are undefinedhigh

no licence file at the repository root

Fix: Add MIT or Apache-2.0 at the repository root.

Add a test suite; this repository has nonehigh54 occurrences

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

Declare least-privilege permissions for GITHUB_TOKENmedium

.github/workflows/ci.yml

1 workflow(s) declare no permissions

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

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

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/ci.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 jobslow

.github/workflows/ci.yml

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