The Problem

Front‑end teams often need a ready‑made admin UI that demonstrates Tailwind CSS utilities, Flowbite components, and charting without writing boilerplate markup. Building that from scratch takes time and introduces inconsistencies across pages.

What This Does

The repository supplies a complete static admin dashboard. Core UI markup lives under layouts/ and content/ (e.g., layouts/_default/dashboard.html, content/authentication/sign‑in.html). Tailwind styling is compiled from src/style.css via tailwind.config.js. JavaScript entry point src/index.js bundles interactive features with Webpack (webpack.config.js). It imports three leaf modules:

  • src/charts.js – registers ApexCharts instances.
  • src/dark-mode.js – toggles the dark class on the <html> element.
  • src/sidebar.js – controls the collapsible navigation drawer.

Static assets (icons, images, flag SVGs) are served from static/. Data for tables and sidebars are in data/ (e.g., data/products.json). The site is intended to be generated with Hugo (presence of .hugo_build.lock, layouts/, content/) and then served as plain files.

How It Is Wired

Execution starts at src/index.js (the only module with outgoing imports). Its import graph (8 modules, 3 edges) is:

src/index.js → { src/charts.js, src/dark-mode.js, src/sidebar.js }
  • src/index.js imports the three leaf modules and does not import anything else (Ca = 0, Ce = 3, instability = 1).
  • Each leaf module (src/charts.js, src/dark-mode.js, src/sidebar.js) has Ca = 1, Ce = 0, so they are only called from src/index.js.

src/index.js is the sole entry point for Webpack; the bundle is emitted to static/js/bundle.js (exact output path is defined in webpack.config.js). The bundle is referenced by the HTML templates (layouts/partials/scripts.html). When a page loads, the script runs:

  1. Dark‑mode init – src/dark-mode.js reads localStorage and toggles the dark class.
  2. Sidebar init – src/sidebar.js attaches click listeners to toggle the navigation drawer.
  3. Chart init – src/charts.js creates ApexCharts objects using data from the page’s DOM.

No module imports form cycles, so a change to any leaf module has a limited blast radius (only the bundle generated by src/index.js is affected). The only deep‑nesting hotspot is src/charts.js (max indentation depth = 7), which could hinder readability.

How To Use It

# Clone the repo
git clone https://github.com/moses-y/admin-dashboard
cd admin-dashboard

# Install dependencies (Yarn lockfile present)
yarn install

# Build the assets – inspect package.json scripts for the exact name,
# typical commands are:
yarn build          # runs webpack with production mode
yarn dev            # runs webpack-dev-server for hot reload (if defined)

# Generate the static site with Hugo (Hugo must be installed)
hugo -D             # -D includes drafts; output goes to ./public

# Serve the result (any static server)
npx serve public

If the package.json scripts differ, use the names listed under "scripts".

Real‑World Use

A SaaS product could mount the generated public/ directory behind an Nginx reverse proxy, using the dashboard as the admin UI while the back‑end API is called directly from the client‑side JavaScript (e.g., via fetch inside src/charts.js). The static nature keeps hosting costs low and allows rapid UI iteration.

Code Health & Issues

  • High – Missing CI – No GitHub Actions or other CI configuration; changes are never automatically built or tested.
  • Medium – Missing Dependabot – Only one manifest (package.json) is present; no Dependabot or Renovate config to keep 18 dependencies up‑to‑date (e.g., jsdom ^17.0.0 vs 30.0.1).
  • Medium – Deep nesting – src/charts.js reaches indentation depth 7, making control flow hard to follow. Refactor with early returns or extract inner blocks.
  • No tests – Repository contains no test files.
  • License – MIT license present.
  • Dockerfile – Not provided; container builds must be added manually if needed.

The Bottom Line

The repo delivers a functional, Tailwind‑styled admin UI with ready‑made pages and interactive components, suitable for projects that need a quick static front‑end. However, the lack of CI, outdated dependencies, and a single deeply‑nested module mean additional engineering effort is required before adopting it in a production pipeline. Ideal for prototyping or as a visual baseline, but not a drop‑in production starter without remediation.