Added frontend CI workflow (TypeScript build/typecheck)

[dubemoyibe-star]

Summary

Adds a dedicated frontend CI workflow to ensure frontend changes are validated before merge.

The repository previously only ran Rust/Soroban contract checks, which meant frontend syntax, type, lint, and build errors could pass through CI unnoticed. This PR introduces a frontend-specific workflow that runs only when files under frontend/** change.

Closes #53

Changes

• Added .github/workflows/frontend-ci.yml

• Configured workflow triggers for:

  • Pushes affecting frontend/**
  • Pull requests affecting frontend/**
  • Manual workflow_dispatch

• Added Node.js 20 setup with npm dependency caching

• Added dependency installation via pnpm ci

• Added TypeScript validation with npx tsc --noEmit

• Added frontend linting with pnpm run lint

• Added production build validation with pnpm run build

• Added CI environment handling for required frontend variables (where applicable)

• Updated project documentation to mention frontend CI checks and what they validate

Validation

• Verified workflow triggers only for changes under frontend/**
• Verified TypeScript checking is included via tsc --noEmit
• Verified production build validation is included via next build
• Verified npm dependency caching is enabled to keep workflow execution fast

Expected Outcome

Frontend PRs now receive automated validation for:

• TypeScript errors
• Syntax errors
• Lint violations
• Build-breaking issues

while avoiding unnecessary CI runs for contract-only changes.

[Sendi0011]

@dubemoyibe-star kindly fix CI erros

[dubemoyibe-star]

@Sendi0011
On it

[Sendi0011]

CI still failing @dubemoyibe-star

[dubemoyibe-star]

@Sendi0011
the failing CI is due to typescript errors on the frontend that wans't caused by me
Should i go ahead with the correction even though it isn't part of the scope of this PR

[Sendi0011]

@Sendi0011 the failing CI is due to typescript errors on the frontend that wans't caused by me Should i go ahead with the correction even though it isn't part of the scope of this PR

I will be much appreciated if you can

[dubemoyibe-star]

@Sendi0011
No problem
im on it

[Sendi0011]

@dubemoyibe-star I pulled the branch and tested this directly to figure out what's actually failing. Good news: tsc --noEmit passes with zero errors, and next build compiles successfully too — so this isn't a pre-existing TypeScript problem like we suspected.
The actual failure is the lint step specifically. Two things are going on: (1) there's no ESLint config file anywhere in frontend/ (no .eslintrc* or eslint.config.mjs), and (2) next.config.mjs has a leftover eslint configuration block that Next.js 16 no longer recognizes at all — you can see the warning about it right at the top of the build output. On top of that, next lint itself was removed in Next.js 16 (deprecated in 15, gone in 16), so npm run lint is calling a command that doesn't exist anymore regardless of any config.
Could you:

Add a minimal eslint.config.mjs (flat config, since that's what Next.js 16 / ESLint 9 expects)
Remove the stale eslint block from next.config.mjs
Update the lint script in package.json to call eslint . directly instead of next lint

This isn't something you introduced — it's a gap in the repo that nothing ever exercised until this workflow tried to run lint for the first time. Should be a small, contained fix within this same PR. Once that's green, this is ready to merge.

[dubemoyibe-star]

@Sendi0011
Thanks for the clarification
ill do that now

[Sendi0011]

@dubemoyibe-star thanks for the fix, can you please resolve conflict in order to approve workflow

[dubemoyibe-star]

@Sendi0011
that certainly didnt fix the failing CI

[Sendi0011]

@Sendi0011 that certainly didnt fix the failing CI

I pulled the latest commit and tested it directly. Good progress — the next.config.mjs/next lint fix is correct. But the new eslint.config.mjs has no TypeScript parser configured, so eslint . now fails with 125 parsing errors across every .ts/.tsx file in the project (it can't parse interface, type annotations, as, etc. — anything TS-specific). Needs @typescript-eslint/parser set as the parser for .ts/.tsx files, plus ideally @typescript-eslint/eslint-plugin and eslint-plugin-react-hooks for real coverage, since right now rules: {} means it'd pass cleanly even with genuine problems in the code.
Also — and this isn't something you need to fix in this PR — tsc --noEmit is failing for reasons unrelated to your workflow. I traced it: there's a real syntax error in group-members.tsx currently on main itself (a merge between two other PRs left a JSX block incorrectly nested), plus a few other pre-existing type errors elsewhere. PR #74 already fixes the group-members.tsx one. I'm filing a separate issue for the rest so it's tracked properly — once that's resolved and the ESLint parser is added here, this workflow should go fully green and actually start doing its job.

[Sendi0011]

@dubemoyibe-star > Update: PR #78 just merged, which fixes the tsc --noEmit errors that were blocking this. Could you pull the latest main into this branch?

git fetch origin
git merge origin/main

After that, one thing still needs fixing here specifically: the eslint.config.mjs you added has no TypeScript parser configured, so eslint . currently fails with 125 parsing errors across every .ts/.tsx file (it can't parse interface, type annotations, as, etc.). You'll need to add @typescript-eslint/parser as the parser for .ts/.tsx files. Also worth adding @typescript-eslint/eslint-plugin and eslint-plugin-react-hooks while you're in there — right now rules: {} is empty, so lint would pass even with real issues in the code.

Once that's in, can you confirm all three pass locally before pushing?

npx tsc --noEmit
npm run lint
npm run build

Once those are clean and the workflow run itself goes green, this is ready to merge.

[dubemoyibe-star]

@Sendi0011
Thanks for the clarification
ill start implementation now

[Sendi0011]

@dubemoyibe-star i found the new failure — good news, it's a quick fix. The parser/plugin additions are right, but languageOptions.parser is set to { ts: tsParser, tsx: tsParser }, which isn't valid flat-config syntax. ESLint's flat config wants the parser module assigned directly, not wrapped in a per-extension map:

languageOptions: {
  globals: { ...globals.browser, ...globals.node },
  parser: tsParser,
  parserOptions: {
    ecmaVersion: 2024,
    sourceType: "module",
  },
},

I tested this fix locally and it resolves the crash. But once that's fixed, you'll hit a second issue: without an ignores block, ESLint scans .next/ (the build output) and reports ~18,000 problems, almost all noise from generated/minified code. Add this at the top of the config's array:

{
  ignores: [".next/**", "node_modules/**", "out/**", "build/**"],
},

With both fixes, I confirmed it locally — lint runs clean against just real source files and reports 96 genuine issues (mostly @typescript-eslint/no-explicit-any and a couple of unused vars). Those 96 are real and will need fixing in the actual source files, but that's expected and healthy for a linter running for the first time — not something to fix in this PR.

Also, separate small thing: the latest commit removes the loading-skeleton UI in group-members.tsx that PR #74 added (replaced with a plain spinner) — was that intentional, or a leftover from debugging? Might be worth reverting just that part if it wasn't meant to change.