DEV Community: Tajudeen Abdulgafar

Taking Repo Context Packager to the Next Level

Tajudeen Abdulgafar — Sun, 30 Nov 2025 05:14:39 +0000

Introduction

In Release 0.3, I built and published repo-context-packager, a CLI tool that helps developers package their repository context for Large Language Models (LLMs). While the initial release (v1.0.3) works well and is available on npm, there is a significant difference between a "working" project and a "professional" open source project.

For Release 0.4, my goal is to bridge that gap. I plan to take this tool from a manual, local-first utility to a fully automated, widely distributable package that follows modern DevOps best practices.

The Plan: What I Will Do

Over the next few weeks, I will focus on four key areas:

1. Remote Repository Support

Currently, users must manually clone a repository before they can package it.

Goal: Allow users to pass a GitHub URL directly (e.g., repo-context-packager https://github.com/user/repo). The tool will clone it to a temporary directory, package it, and clean up automatically. This significantly reduces friction for quick analysis.

2. Security Redaction

Pasting code into LLMs carries a risk: accidentally leaking API keys or credentials.

Goal: Implement a --safe flag that scans files for potential secrets (AWS keys, private keys, .env variables) and replaces them with [REDACTED]. This makes the tool safer for enterprise use.

3. Automating the Release Process (CI/CD)

Currently, releasing a new version involves a manual checklist: running tests, building the project, bumping versions, and running npm publish. This is prone to human error.

Goal: Implement a GitHub Actions workflow that automatically tests every PR and publishes new versions to npm whenever a new release tag is pushed.

4. Expanding Distribution

While npm install -g is standard for Node.js developers, many macOS users prefer Homebrew for managing CLI tools.

Goal: Create a Homebrew Tap for repo-context-packager, allowing users to install it via brew install repo-context-packager. This lowers the barrier to entry and makes updates easier to manage.

Why This Work Matters

I chose to continue working on repo-context-packager because it solves a real problem I face daily: giving LLMs the right context. However, the engineering motivation for Release 0.4 is to master the "meta" skills of software development:

Feature Development: Adding remote repository support and security redaction involves handling temporary files, git operations, and regex pattern matching—a great exercise in robust Node.js development.
DevOps & Automation: Writing code is only half the job. Ensuring that code can be reliably tested and deployed is what separates hobby projects from professional engineering. Learning GitHub Actions in depth is a career-relevant skill.
User Experience: Making installation seamless (via Homebrew) shows respect for the user's time. It shifts the focus from "how do I run this?" to "how do I use this?"
Maintainability: By automating the tedious parts of maintenance, I make it easier for myself (and future contributors) to keep the project alive.

The Approach

Here is my roadmap for the coming weeks:

Week 1 (Planning): Defining the scope (this post) and researching GitHub Actions for npm publishing.
Week 2 (Features & Automation):
- Implement Remote Repository Support (clone -> package -> cleanup).
- Implement Security Redaction (regex-based secret scanning).
- Set up a CI pipeline to run tests on every Pull Request.
- Set up a CD pipeline to publish to npm on git tag creation.
- Deliverable: A new feature release (v1.1.0) and automated pipeline.
Week 3 (Distribution & Polish):
- Create a Homebrew formula and Tap.
- Incorporate user feedback (bug fixes/UI tweaks).
- Finalize documentation (CHANGELOG, badges).
- Deliverable: A polished, professional open source repository.

Conclusion

Release 0.4 is about maturity. It's about taking a raw tool and wrapping it in the professional infrastructure it needs to thrive. By the end of this term, repo-context-packager won't just be a piece of code—it will be a robust, automated, and easily installable product.

Implementing Authentication Middleware in Next.js with i18n Support

Tajudeen Abdulgafar — Sat, 22 Nov 2025 04:03:36 +0000

Introduction

Building secure web applications requires implementing proper authentication and authorization mechanisms. In Next.js applications, middleware provides an excellent way to protect routes and handle authentication before requests reach your pages. This blog post will walk you through implementing a robust authentication middleware that seamlessly integrates with internationalization (i18n) routing for library_proj, one of the project I contributed to doing the hacktoberfest.

Why Authentication Middleware?

Authentication middleware sits between the client request and your application logic, allowing you to:

Protect routes before they're rendered
Redirect unauthenticated users to login pages
Preserve intended destinations with redirect parameters
Prevent authenticated users from accessing auth pages
Centralize authentication logic for better maintainability

By handling authentication at the middleware level, you ensure security checks happen early in the request lifecycle, before any server-side rendering or data fetching occurs.

Architecture Overview

The authentication middleware works in conjunction with Next.js App Router and includes:

Request → Middleware → Authentication Check → Route Protection → i18n Routing → Response

The middleware performs these checks in order:

Extract locale from the pathname or browser preferences
Check authentication status via cookies
Determine route type (public vs. protected)
Apply redirects based on authentication state
Handle locale routing for proper i18n support

Implementation Details

Authentication Check

The middleware checks for authentication tokens stored in cookies. It supports multiple token types for flexibility:

function isAuthenticated(request: NextRequest): boolean {
  const authToken = request.cookies.get('auth_token');
  const sessionToken = request.cookies.get('session_token');

  // Check for either auth_token or session_token
  return !!(authToken || sessionToken);
}

Route Classification

The middleware distinguishes between public and protected routes:

Public Routes

Routes accessible without authentication:

/login
/signup
/register
/forgot-password
/reset-password

Protected Routes

By default, all routes are protected except those explicitly marked as public. This includes:

Dashboard routes (/, /my_books, /books)
Profile and settings pages
Any other application routes

Protection Logic

function isProtectedRoute(pathname: string): boolean {
  const pathWithoutLocale = getPathnameWithoutLocale(pathname);

  // If it's a public route, it's not protected
  if (isPublicRoute(pathname)) {
    return false;
  }

  // All other routes are protected by default
  return true;
}

This "secure by default" approach ensures that new routes are automatically protected unless explicitly added to the public routes list.

Key Features

1. Automatic Route Protection

All routes are protected by default, reducing the risk of accidentally exposing sensitive pages.

2. Smart Redirects

Unauthenticated users accessing protected routes are redirected to /login with a redirect parameter
Authenticated users accessing auth pages (login, signup) are redirected to the home page
Locale is preserved in all redirects

3. i18n Integration

The middleware seamlessly handles internationalization:

Extracts locale from pathname
Preserves locale during redirects
Works with browser language preferences

4. Server Component Support

Authentication status is exposed via headers for server components:

response.headers.set('x-authenticated', authenticated ? 'true' : 'false');

Server components can access this header to conditionally render content:

// In a server component
const headers = await headers();
const isAuthenticated = headers.get('x-authenticated') === 'true';

Best Practices

1. Secure Cookie Settings

When setting authentication cookies, use secure settings:

// In your login handler
cookies().set('auth_token', token, {
  httpOnly: true,    // Prevent XSS attacks
  secure: process.env.NODE_ENV === 'production', // HTTPS only in production
  sameSite: 'lax',   // CSRF protection
  maxAge: 60 * 60 * 24 * 7, // 7 days
  path: '/',
});

2. Token Validation

For production, consider validating tokens server-side:

async function isAuthenticated(request: NextRequest): Promise<boolean> {
  const token = request.cookies.get('auth_token')?.value;
  if (!token) return false;

  try {
    // Validate token with your backend
    const response = await fetch(`${BACKEND_URL}/api/auth/verify`, {
      headers: { Authorization: `Bearer ${token}` }
    });
    return response.ok;
  } catch {
    return false;
  }
}

3. Error Handling

Add proper error handling for edge cases:

try {
  // Middleware logic
} catch (error) {
  console.error('Middleware error:', error);
  // Fallback: allow request but log error
  return NextResponse.next();
}

4. Testing

Test your middleware with different scenarios:

✅ Unauthenticated user accessing protected route → redirects to login
✅ Authenticated user accessing login → redirects to home
✅ Authenticated user accessing protected route → allowed
✅ Locale preservation during redirects
✅ Public routes accessible without authentication

Conclusion

Implementing authentication middleware in Next.js provides a robust, centralized way to protect your application routes. By combining authentication checks with i18n routing, you create a seamless user experience that works across different languages and locales.

Publish the repo-context-packager

Tajudeen Abdulgafar — Sat, 22 Nov 2025 02:00:04 +0000

Introduction

After weeks of development, testing, and CI setup, it was time to share this tool with the world. The Repository Context Packager had proven useful locally, but making it installable via npm would let others use it without cloning the repo. Well, this is not my first npm release, but this blog documents my journey from a local CLI tool to a published npm package—the challenges, solutions, and lessons learned along the way.

Executive Summary

Chose npm as the package registry (the standard for Node.js/TypeScript projects)
Published as scoped package: @tajudeen/repo-context-packager@1.0.3
Configured package.json with bin field for CLI installation, files field for clean publishing, and postbuild script for shebang injection
Resolved package name conflict by using scoped package naming
Updated README.md with clear installation and usage instructions
Created git tags (v0.9.0 for practice, v1.0.3 for release)

The tool is now installable globally via npm install -g @tajudeen/repo-context-packager and ready for user testing.

Choosing the Release Tool and Package Registry

Why npm?

For a Node.js/TypeScript CLI tool, npm (Node Package Manager) was the obvious choice:

Native support: npm is built into Node.js, so every user already has it
CLI tool support: npm's bin field makes it trivial to create globally installable commands
Wide adoption: Most JavaScript/TypeScript developers are familiar with npm
Free for public packages: Publishing public packages to npm is free and straightforward

The Release Process: Step by Step

Step 1: Preparing package.json

Before publishing, I needed to configure package.json for CLI distribution:

Added `bin` Field

The bin field tells npm which file to use as the executable command:

{
  "bin": {
    "repo-context-packager": "dist/cli.js"
  }
}

This allows users to run repo-context-packager after installing globally.

Added `files` Field

The files array controls what gets published. I wanted to exclude source files, tests, and development configs:

{
  "files": [
    "dist",
    "README.md",
    "LICENSE"
  ]
}

This reduced the package size from ~90KB to ~20KB by excluding:

src/ (TypeScript source files)
node_modules/ (dependencies are installed separately)
Test files (not needed for runtime)
Development configs (tsconfig.json, vitest.config.ts, etc.)

Updated `main` Field

Changed from pointing to source to compiled output:

{
  "main": "dist/cli.js"  // Was: "src/cli.ts"
}

Added `postbuild` Script

TypeScript doesn't preserve shebangs, so I added a postbuild script to inject #!/usr/bin/env node:

{
  "scripts": {
    "postbuild": "node -e \"const fs=require('fs');const f='dist/cli.js';const c=fs.readFileSync(f,'utf8');if(!c.startsWith('#!'))fs.writeFileSync(f,'#!/usr/bin/env node\\n'+c);\""
  }
}

This ensures the compiled JavaScript can be executed directly as a CLI tool.

Step 2: Creating Practice Tags

Following best practices, I created a practice tag first:

git tag -a v0.9.0 -m "Practice release v0.9.0"
git push --follow-tags

This let me verify the tagging process worked before creating the real release tag.

Step 3: Building and Testing

Before publishing, I ensured everything compiled and tested correctly:

npm run build      # Compile TypeScript
npm run test:run   # Run test suite

Step 4: The First Publishing Attempt

My first attempt failed with a 403 error:

npm error 403 403 Forbidden - PUT https://registry.npmjs.org/repo-context-packager
npm error 403 You do not have permission to publish "repo-context-packager"

The Problem: The package name repo-context-packager was already taken by a classmate (cynthiafotso).

The Solution: Use a scoped package name. Scoped packages are namespaced under your npm username:

{
  "name": "@tajudeen/repo-context-packager"
}

Scoped packages are private by default, so I needed to publish with the --access public flag:

npm publish --access public

Step 5: Version Bumping and Republishing

After resolving the name conflict, I bumped the version and published:

# Updated package.json version to 1.0.3
npm run build
npm publish --access public

Success! The package was published as @tajudeen/repo-context-packager@1.0.3.

Step 6: Verifying Installation

I tested the installation in a fresh directory:

cd /tmp
mkdir test-install
cd test-install
npm install -g @tajudeen/repo-context-packager
repo-context-packager --help

The CLI worked perfectly! ✅

Step 7: Creating the Release Tag

After successful publishing, I created the git tag:

git tag -a v1.0.3 -m "Release v1.0.3 - Published to npm"
git push --follow-tags

What I Learned:

Challenge 1: Package Name Conflicts

The Issue: I assumed repo-context-packager would be available, but it was already taken.

The Lesson: Always check package name availability before finalizing your project name, or use scoped packages from the start. Scoped packages (@username/package-name) are less likely to conflict and clearly indicate ownership.

How to Check:

npm view package-name  # Returns 404 if available

Challenge 2: Scoped Packages Are Private by Default

The Issue: After switching to a scoped package, my first publish attempt seemed successful, but the package wasn't visible when trying to install it.

The Lesson: Scoped packages default to private. You must explicitly publish with --access public for public packages:

npm publish --access public

User Testing Session (Planned)

As of this writing, user testing is scheduled but not yet completed. The plan is to:

Ask a colleague or friend to install the package fresh:

   npm install -g @tajudeen/repo-context-packager

Have them follow the README and try packaging a repository
Observe and take notes on:
- Where they get stuck
- What's unclear in the documentation
- Any installation issues
- Whether the CLI commands are intuitive
Update README based on feedback (per Instruction.md Step 7)

I'll update this blog post after the user testing session with findings and improvements made.

Lessons Learned

Scoped packages prevent conflicts: Using @username/package-name avoids name collisions and clearly shows ownership.
The files field is essential: Explicitly controlling what gets published keeps packages lean and professional.
Shebangs matter for CLI tools: Without #!/usr/bin/env node, globally installed packages won't execute directly.
Test installation before celebrating: Always verify the package installs and works in a fresh environment.
Documentation is part of the release: Updated README with installation instructions is crucial for user adoption.
Version management matters: Using semantic versioning (semver) helps users understand compatibility and changes.

Future Improvements

Automate releases with GitHub Actions: Set up a workflow that automatically publishes to npm when a new tag is pushed.
Add more installation methods: Consider providing installation via:
- Homebrew (for macOS users)
- Direct download links
- Docker image
Version badges: Add npm version badges to README.md to show current version.
Release notes: Create a CHANGELOG.md to document changes between versions.
User testing feedback: After user testing, incorporate feedback into documentation and potentially code improvements.

Conclusion

Publishing to npm transformed the Repository Context Packager from a local development tool into a shareable, installable package. The process was smoother than expected, with most challenges resolved by understanding npm's conventions (scoped packages, files field, shebang injection).

The key takeaway: good project structure makes publishing easy. Because the project already had proper TypeScript compilation, dependency management, and build scripts, the publishing process required minimal code changes—mostly just configuration.

Now that the tool is published, the next steps are user testing, gathering feedback, and iterating based on real-world usage. This is where the real learning begins!

NPM RELEASE

npm Package: @tajudeen/repo-context-packager

Building Confidence: CI, Local Tests

Tajudeen Abdulgafar — Sat, 15 Nov 2025 03:13:16 +0000

Introduction

This week, I set up automated test runs using GitHub Actions, cleaned up and strengthened our Vitest cases for the utility functions, and wrote documentation to help bring these practices into other repos. Now we’ve got a workflow that flags issues right away and encourages contributors to keep our quality standards high.

Why Continuous Integration Was the Missing Piece

Until this week, the project relied on developers remembering to run npm test before pushing. That’s fine when you’re solo and hyper-disciplined, but it doesn’t scale. CI rebuilds on neutral infrastructure, executes the Vitest suite, and blocks merges when tests fail.

Executive Summary

Added a GitHub Actions workflow (.github/workflows/ci.yml) that runs npm ci and npm run test:run on every push or pull request targeting main.
Hardened src/utils.test.ts with boundary cases, empty-input handling, and multi-line formatting checks so regressions surface immediately.
Outlined an upstream contribution plan (UtilsIncludeTest in tests/utils_test.cpp) to ensure onlyIncludedExtensions handles real-world include lists, whitespace, negative matches, and empty configurations.

The repository now fails fast when tests break, documents how to keep contributions safe, and provides a blueprint for sharing those habits beyond this codebase.

Workflow Highlights

name: CI
on:
  push:
    branches: [ "main" ]
  pull_request:
    branches: [ "main" ]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
      - run: npm ci
      - run: npm run test: run

Key lessons:

YAML indentation matters: My first draft began with - name: CI, so GitHub treated the workflow as an array element and ignored it. Removing the dash turned the lights on.
Lock files are non-negotiable: actions/setup-node with cache: npm refuses to run if it can’t find package-lock.json. Before this, I didn't include package-lock in the project; I made it ignore it, committing the lock file, which unblocks deterministic installs.
Red → Green confidence: I intentionally broke a test, let CI fail, studied the logs, and then fixed it. Watching the status flip from red to green proved that the workflow really guards the repo.

Leveling Up With Automated Testing

Tajudeen Abdulgafar — Fri, 07 Nov 2025 23:06:22 +0000

Introduction

This week, I embark on a journey of Testing, which is one of the interesting aspects of Programming. Sometimes you will think you've got everything covered, but no, there are lots of loopholes than you think. So, for this Testing, I went with Vitest.

Why Vitest?

Automated testing was the focus for this lab, so I needed a framework that matched the TypeScript-first nature of the project. I compared Jest and Vitest, and ultimately went with Vitest (docs) because:

It runs tests directly against modern JS/TS without extra transpilation glue.
Watch mode and focused test runs are built-in (vitest --watch, vitest run --filter ...).
Coverage via the @vitest/coverage-istanbul plugin is a single flag away.
The CLI feels familiar coming from Jest, so there was very little learning curve.

The only snag was peer dependency alignment: Vitest 4 expects @types/node ≥ 20, while the project was still on 14. Bumping the type definitions resolved the install conflict without touching runtime Node requirements.

Framework Setup

Getting Vitest wired in was straightforward:

Installed the packages: npm i -D vitest @vitest/coverage-istanbul.
Added a tiny vitest.config.ts to ensure we use the Node environment and to configure coverage reporters.
Replaced the placeholder npm test script with vitest, added helpers for single runs and watch mode, and exposed coverage via npm run test:coverage.
Documented the commands in README.md so anyone on the team can run the right workflow quickly.

At this point, npm test ran (and passed) an empty suite—mission accomplished for Step 1.

Building the Test Suite

I started small, writing the very first unit tests around the easiest pure functions:

calculateTokens, formatOutput, and truncateContent in src/utils.ts.

These covered happy paths as well as a couple of edge cases (rounding behaviour and truncation markers). Once that foundation was in place, I layered on additional suites for other parts of the codebase:

Repository statistics – verified that RepositoryStatistics correctly tracks totals, token counts, directory sets, averages, limit checks, and reset behaviour.
Summarizer – confirmed that imports, exports, and function metadata are captured, and that the formatted output includes the right cues for summary mode. While writing these tests I discovered that async exports weren’t being picked up; fixing the regex so it recognises export async function resulted in the first “aha!” bug found by testing.
Packager – used Vitest’s filesystem-friendly test runner to spin up temporary directories, mock Git metadata, and exercise the higher-level workflow. These tests proved that the CLI can:
- Analyse files and accumulate RepoInfo.
- Generate summary-mode output without throwing.
- Respect maxFileSize limits and skip oversized files.

Altogether the suite now has 12 tests, touching everything from helper utilities to integration-style Packager runs.

Running Focused Tests (Step 4)

One pain point with larger projects is rerunning the entire suite while iterating on a single failing test. Vitest’s command-line options make this easy:

npm run test:watch keeps tests hot-reloading as files change.
npm run test:file -- src/packager.test.ts scopes execution to one file.
npm run test:run -- --filter "Packager" is handy when I just want the Packager suite.

These scripts, together with the README notes, satisfied Step 4’s “test runner improvements” goal.

Optional Coverage

Although not strictly required, the coverage command (npm run test:coverage) is ready to go thanks to the Istanbul plugin. Running it highlights remaining gaps—logger helpers and some CLI validation branches are still untested—which gives me a roadmap for future edge-case coverage.

Lessons Learned

Targeted unit tests surface subtle bugs. Without the summarizer tests, I might never have noticed async exports disappearing.
Type alignment matters. Even small dependencies like @types/node can block installation; upgrading them early avoids wasted time.
Integration-style tests add confidence fast. The Packager suite spins up temporary workspaces, letting me verify real workflows without touching the actual filesystem.

Overall, this lab reinforced that investing in a clean testing setup unlocks safer refactoring and faster iteration. The Repository Context Packager now has a reliable safety net, and I’m more confident shipping improvements in the future.

My Hacktoberfest 2025 Journey

Tajudeen Abdulgafar — Sat, 01 Nov 2025 03:30:34 +0000

My Hacktoberfest 2025 Journey: Learning Through Open Source

Hacktoberfest 2025 was my first deep dive into open source contribution, and it taught me far more than I expected—not just about code, but about collaboration, communication, and understanding what projects actually need.

The Wins

PhysicsHub Theme Overhaul

My first major contribution focused on improving the light theme for PhysicsHub. The original design used overly bright colors that caused eye strain, so I softened the palette and improved contrast ratios across the board. I also simplified the theme toggle from a confusing three-mode cycle to a straightforward light/dark switch.

Beyond the visual improvements, I refactored the entire theme system to eliminate hardcoded colors, making every component properly theme-aware. The simulation pages, chapter cards, and code blocks now seamlessly adapt to user preferences.

Dark Mode Bug Fixes & Architecture Improvements

My second PhysicsHub contribution tackled critical visibility issues. The Stars components were nearly invisible in dark mode, and the homepage radial glow wasn't showing up at all due to z-index conflicts. After fixing these visual bugs, I refactored the project structure to use a centralized Layout component instead of duplicating headers and footers across every page.
This architectural change might seem invisible to users, but it dramatically improved code maintainability and fixed footer positioning issues across the site.

Frontend Authentication System

For a Next.js project, I built a complete frontend-only authentication system with login and signup pages supporting both English and Japanese locales. Using localStorage for persistence and Zod for validation, I created a self-contained auth flow that works immediately while leaving room for future backend integration.

The implementation includes reusable UI components, localized error messages, and session management that survives page refreshes.

The Learning Experience

Integration URL History (Closed Without Merge)

Not every contribution makes it into the codebase, and that's okay. I built a URL history feature for an integration drawer that stored up to 10 previously used URLs per integration type in localStorage. It worked perfectly—but it wasn't what the project needed.

The maintainer's feedback was direct: "It feels like too many changes for something very simple—I'd just like to see a list of what's already configured." I had interpreted "add history option" as building a comprehensive memory system when they simply wanted to display existing configurations.

What I Learned

Communication Matters More Than Code

The closed PR taught me the most important lesson: always clarify requirements before diving into implementation. During Hacktoberfest, there's pressure to contribute quickly, but taking time to understand what maintainers actually want saves everyone time and effort.

Theme Systems Are Complex

Working on PhysicsHub's theme system showed me how deeply colors affect user experience. It's not just about aesthetics—proper contrast ratios impact accessibility, and consistent theming across components requires careful architectural planning.

Architecture Beats Duplication
Refactoring duplicated headers and footers into a centralized Layout component was straightforward, but the impact was significant. Good architecture makes future changes easier, and that matters more than clever individual solutions.
Frontend-First Can Work
Building authentication without waiting for backend infrastructure proved that you can create functional features by working within constraints. localStorage isn't a database, but for the right use case, it enables rapid prototyping and immediate user value.

Moving Forward
Hacktoberfest reminded me that open source isn't just about writing code—it's about understanding problems, communicating solutions, and being willing to adjust when you miss the mark. The merged PRs feel great, but the closed one taught me more.

Next year, I'll ask more questions upfront, contribute to projects where I genuinely use the software, and remember that simpler solutions often beat clever ones.

Stats:

4 Pull Requests submitted
3 Merged successfully
1 Closed (with valuable lessons learned)
2 Projects contributed to
Countless lines of code refactored

Thanks to all the maintainers who reviewed my work, provided feedback, and helped me grow as a developer. See you in Hacktoberfest 2026! 🎃

Building a Frontend-Only Authentication System

Tajudeen Abdulgafar — Sat, 01 Nov 2025 03:20:52 +0000

Hactoberfest fourth week

I implemented a complete authentication system for a Next.js project, adding login and signup functionality that works entirely on the frontend using localStorage for data persistence.

What I Built

Authentication Pages
I created fully functional login and signup pages with routes for both English (/en/login, /en/signup) and Japanese (/ja/login, /ja/signup) locales. Each page includes form components with proper validation and error handling.

Client-Side Authentication Logic
The authentication system lives entirely in the browser. I built a utility module (auth-client.ts) that handles user session management, including getCurrentUser() and setCurrentUser() functions. User data persists in localStorage, and sessions automatically restore when users return to the site.

Form Validation

Using Zod, I created validation schemas for both login and signup forms. These schemas validate email formats, password requirements, and full name fields, with localized error messages that adapt to the user's language preference.

UI Enhancements
I added a reusable Input component to maintain consistency across forms and integrated logout buttons into both the main sidebar and mobile sidebar, giving users a clear way to end their sessions.

Internationalization

All auth-related text supports both English and Japanese, from form labels and placeholders to success messages and validation errors. This ensures a seamless experience regardless of language preference.

Technical Approach

Rather than waiting for backend infrastructure, I implemented a self-contained frontend authentication system. This approach allows the UI to be fully functional immediately while leaving room for backend integration later (I even kept the server actions structure in place for future use).

The validation layer ensures data integrity before it ever touches localStorage, and the session management handles edge cases like page refreshes and navigation between routes.

Hacktoberfest 2025 Contribution
Issue #13 | Pull Request #20

Adding URL History to Integration Creation

Tajudeen Abdulgafar — Sat, 01 Nov 2025 03:13:50 +0000

Hactoberfest third week

I implemented a URL history feature for PhysicsHub's integration drawer, making it easier to reuse previously entered URLs when creating integrations.

What I Built

When you open the integration creation drawer now, you'll see a dropdown showing your previously entered URLs. This autocomplete feature remembers up to 10 URLs per integration type (Grafana, Kibana, Datadog, etc.) and stores them in localStorage.

I created a new utility file (integrationUrlHistory.ts) to handle the URL history management and modified the Integrations page to load, display, and save URLs as users work with integrations. I also fixed some type-related errors that were lingering in the codebase.

Why It Didn't Work Out
The PR was closed without merging, and honestly, the feedback made sense. The maintainer pointed out that the implementation felt overcomplicated for what should be a simple feature—they just wanted to see a list of already configured integrations, not a full history system with localStorage management.

Sometimes you build something thinking you're solving the problem elegantly, only to realize you've added unnecessary complexity. The feature worked, but it wasn't what the project actually needed. It's a good reminder to clarify requirements before diving into implementation, especially during Hacktoberfest when you're eager to contribute.

Lessons Learned
Always make sure you understand the actual problem before proposing a solution. "Add history option" could mean many things, and I interpreted it as building a comprehensive URL memory system when a simpler approach would have sufficed.

Hacktoberfest 2025 Contribution
Issue #466 | Pull Request #467 (Closed without merge)

Fixing Dark Mode Issues

Tajudeen Abdulgafar — Sat, 01 Nov 2025 03:09:09 +0000

Hactoberfest sencond week

For the second week, I worked on the same issue due to a miscommunication. I tackled critical visual bugs and implemented architectural improvements to PhysicsHub that improved the user experience, especially in dark mode.

What I Fixed

Dark Mode Visibility Issues
The Stars components scattered across various pages were practically invisible in dark mode. I updated them to use a brighter color (#AEE3FF) that maintains proper visibility in both light and dark themes. No more squinting to see those decorative stars!
The homepage had another issue—the radial glow effect wasn't showing up in dark mode at all. After digging into the z-index layering and transparency settings, I resolved the conflicts that were hiding this visual element.

React Architecture Overhaul
The project was repeating Header and Footer components on every single page, which isn't just inefficient—it makes maintenance a nightmare. I refactored the entire structure to use a centralized Layout component. Now the header and footer live in one place, wrapping all page content automatically.

This also fixed footer positioning issues. Using proper flexbox layout, the footer now consistently stays at the bottom of the page regardless of content height.

Why This Matters
Dark mode shouldn't feel like a half-finished feature. These visibility fixes ensure users get a consistent, polished experience whether they prefer light or dark themes.

The architectural changes might seem invisible to users, but they make the codebase significantly cleaner and easier to maintain. Future contributors won't have to update headers and footers in multiple places, and the layout behavior is now predictable across all pages.

Hacktoberfest 2025 Contribution
Issue #15 | Pull Request #70

Improved Theme System

Tajudeen Abdulgafar — Sat, 01 Nov 2025 03:03:41 +0000

Hactoberfest first week

For the first week of Hactoberfest. I refined the light theme on PhysicsHub to create a more comfortable, accessible, and consistent experience across the platform

What I Changed
The light theme got a complete refresh. I replaced the overly bright backgrounds with softer, easier-on-the-eyes colors. Those harsh whites and near-whites (#e8eefb, #f6f7fb) are now gentler shades (#d1d9e8, #dde6f0) that reduce eye strain during extended use.

I also simplified how theme switching works. Instead of cycling through three modes (dark → light → system), users now get a straightforward light/dark toggle. The preference persists across sessions, so the app remembers what you like.

Under the hood, I fixed theme handling across the entire application. Simulation pages, chapter cards, code blocks, and other components now properly adapt to the chosen theme instead of using hardcoded colors. I also improved text contrast, making content more readable in light mode.

Why It Matters

The original light theme was too aggressive. Extended reading sessions meant squinting at bright backgrounds, which isn't ideal for anyone spending serious time with the content.

These changes improve accessibility through better contrast ratios, create a more consistent experience across all pages, and make the codebase more maintainable by eliminating hardcoded color values. Plus, the simpler toggle makes switching themes feel natural rather than confusing.

Hacktoberfest 2025 Contribution
Issue #15 | Pull Request #46

Refactoring Journey: Improving Code Quality

Tajudeen Abdulgafar — Sat, 11 Oct 2025 03:01:15 +0000

Introduction

This week, I embarked on a comprehensive refactoring journey for my Repository Context Packager project. The goal wasn't to add new features or fix bugs, but rather to improve the code's structure, readability, maintainability, and squashing all my commits to just one, paying down technical debt that had accumulated during rapid development.

What I Focused On

My refactoring efforts centered on six key areas, all guided by software engineering principles like DRY (Don't Repeat Yourself), Single Responsibility Principle (SRP), and SOLID principles:

1. Reducing Code Duplication

I found the same token calculation formula (Math.round(content.length / 4)) repeated in two different places. This is a classic DRY violation—if the formula needed updating, I'd have to remember to change it in multiple locations.

2. Improving Function Modularity

The command-line option parsing logic was something else, lines of repetitive if-statements, all doing basically the same thing with slight variations. I changed that as well, thanks to Cursor for this.

3. Breaking Down Large Functions

The main action callback function was a monster at 110 lines, handling validation, parsing, execution, and output all in one place. This violated the Single Responsibility Principle spectacularly.

How I Fixed Each Issue

Refactoring #1: Extract Default Ignore Patterns

Before:

export async function collectFiles(...) {
  const defaultIgnore = [
    'node_modules/**', 
    '.git/**', 
    '*.log',
  ];
}

After:

const DEFAULT_IGNORE_PATTERNS = [
  'node_modules/**', 
  '.git/**', 
  '*.log',
];

export async function collectFiles(...) {}

Impact: This made the ignore patterns easy to find, document, and modify without touching function logic.

Refactoring #2: Extract Token Calculation Function

Before:

const fileTokens = Math.round(content.length / 4);
return files.reduce((total, file) => total + Math.round(file.content.length / 4), 0);

After:

export function calculateTokens(content: string): number {
  return Math.round(content.length / 4);
}
const fileTokens = calculateTokens(content);

Impact: Single source of truth for token calculation. If the formula changes, update it once.

Refactoring #3: Extract Option Parsing Logic

Before:

.action(async (paths, options) => {
  const packagerOptions = {};

  if (options.include) {
    packagerOptions.include = options.include.split(',').map((p: string) => p.trim());
  }
  if (options.exclude) {
    packagerOptions.exclude = options.exclude.split(',').map((p: string) => p.trim());
  }
});

After:

function parseCommandLineOptions(options: any): PackagerOptions {
  const packagerOptions: PackagerOptions = {};

  if (options.include) {
    packagerOptions.include = options.include.split(',').map((p: string) => p.trim());
  }

  return packagerOptions;
}

.action(async (paths, options) => {
  const packagerOptions = parseCommandLineOptions(options);
});

Impact: The action callback became readable. Option parsing is now testable in isolation.

Refactoring #4: Split Large Action Function

Before:

.action(async (paths, options) => {
  // 110 lines of:
  // - input validation
  // - option parsing
  // - output validation
  // - execution
  // - result display
  // - error handling
});

After:

function validateInputPaths(paths: string[]): void { /* ... */ }
function validateOutputPath(outputFile: string): void { /* ... */ }
async function executePackaging(...): Promise<void> { /* ... */ }
function displayResults(...): void { /* ... */ }

.action(async (paths, options) => {
  validateInputPaths(paths);
  const packagerOptions = parseCommandLineOptions(options);
  const outputFile = options.output || 'output.md';
  validateOutputPath(outputFile);

  try {
    await executePackaging(paths, packagerOptions, outputFile);
    displayResults(outputFile, !!options.output);
  } catch (error) {
    console.error(chalk.red(`❌ Error: ${(error as Error).message}`));
    process.exit(1);
  }
});

Impact:

Action callback reduced from 110 lines to 24 lines
Each function has one clear purpose
Much easier to test and debug
Other parts of the codebase can reuse these functions

Refactoring #5: Extract Statistics Collection Class

Before:

// Inside the 167-line analyzeRepository() method:
let currentTokens = 0;
const fileTypes: Record<string, number> = {};
let largestFile: { path: string; lines: number } | null = null;
let totalCharacters = 0;
const processedDirectories = new Set<string>();

// 50 lines of statistics tracking mixed with file processing

After:

// New statistics.ts file
export class RepositoryStatistics {
  private totalCharacters: number = 0;
  private fileTypes: Record<string, number> = {};
  private largestFile: { path: string; lines: number } | null = null;

  public trackFile(fileInfo: FileInfo): void { /* ... */ }
  public wouldExceedTokenLimit(content: string, maxTokens?: number): boolean { /* ... */ }
  public getTotalCharacters(): number { /* ... */ }
}

// In packager.ts:
const stats = new RepositoryStatistics();
stats.trackFile(fileInfo);

Impact:

Statistics logic is now reusable and testable
analyzeRepository() became much more readable
Clear separation of concerns

Refactoring #6: Create Error Handling Utilities

Before:

// Scattered throughout the code:
process.stderr.write(`Error: File '${filePath}' not found\n`);
process.stderr.write(`Warning: File '${filePath}' no longer exists, skipping\n`);
process.stderr.write(`Skipping ${filePath}: file too large\n`);

After:

// New logger.ts file
export function logError(message: string): void {
  process.stderr.write(`Error: ${message}\n`);
}

export function logWarning(message: string): void {
  process.stderr.write(`Warning: ${message}\n`);
}

export function logFileError(filePath: string, error: any): void {
  if (error.code === 'ENOENT') {
    logError(`File '${filePath}' not found`);
  } else if (error.code === 'EACCES') {
    logError(`Permission denied reading '${filePath}'`);
  }
  // ... smart error handling
}

// In packager.ts:
logError(`Path '${singlePath}' does not exist`);
logWarning(`File '${filePath}' no longer exists, skipping`);
logFileError(filePath, error);

Impact:

Consistent error message formatting
Centralized logging makes it easy to add features like log levels or file logging
Semantic function names make code self-documenting

The Git Rebase Experience

This is where things got interesting! The instructions called for an interactive rebase to squash all commits into one. Here's what happened:

Initial Attempt: Branch-Based Refactoring Workflow

Instead of performing everything directly on the main branch, I decided to use a safer and cleaner approach by creating a separate refactoring branch.

Step 1: Update `main`

I started by ensuring my local main branch was up to date:

git checkout main
git pull origin main

Step 2: Create a Refactoring Branch

Next, I created a new branch for all my refactoring work:

git checkout -b refactoring

Step 3: Make and Commit Changes

I made several improvements across the codebase, committing each logical change separately:

git add .
git commit -m "Refactored helper functions for clarity"
git commit -m "Simplified data handling logic"
git commit -m "Improved maintainability and readability"

Step 4: Squash Commits

After testing and reviewing, I decided to squash the multiple commits into one for a cleaner commit history:

git reset --soft HEAD~6
git commit -m "Refactoring codebase to improve maintainability and code quality"

The --soft flag preserved all staged changes while removing the last 6 commits, allowing me to create one detailed and consolidated commit.

Step 5: Merge Back to `main`

Once everything looked good, I merged the refactoring branch back into main using a fast-forward merge:

git checkout main
git merge --ff-only refactoring  # <-- This ensures a clean, linear history

Step 6: Push to GitHub

Finally, I pushed my updated main branch to GitHub:

git push origin main

This worked perfectly!
This branch-based approach kept my main branch stable, avoided interactive rebase editor issues, and resulted in a clear and professional commit history.

Did I Find Any Bugs?

Surprisingly, no bugs were found during refactoring! However, the refactoring process did reveal several code smells and potential issues:

Hidden Complexity
Testing Difficulty
Maintenance Risks

Did I Break Anything?

Test after each commit: After every refactoring step, I ran:

   npm run build

This ensured TypeScript compilation succeeded and no syntax errors were introduced.

What Went Well:

Incremental commits: Making 6 small commits made the refactoring process manageable
Clear commit messages: Each commit message explained exactly what changed
Soft reset technique: When interactive rebase failed, the soft reset approach was actually simpler and more intuitive

Conclusion

The codebase is now significantly more maintainable, and I'm confident that future changes will be easier to implement. When we write automated tests later, having modular, focused functions will make that process much smoother.

Most importantly, this exercise taught me that refactoring isn't just about cleaning code—it's about making your future self's life easier.

Parallel Branch Development with Git

Tajudeen Abdulgafar — Sat, 27 Sep 2025 01:32:43 +0000

Introduction

This week, I dive deep into one of Git's most powerful features: parallel branch development. Still working on my Repository Context Packager project, I implemented two distinct features simultaneously using separate branches, then merged them back into main. This perfectly demonstrated how Git enables multiple development streams without interference.

The Challenge: Two Features, One Timeline

For this exercise, I chose to implement:

Verbose Mode Flag (Issue #12) - Add --verbose/-v flag for detailed progress output
Enhanced Statistics (Issue #13) - Expand summary with file type breakdowns and detailed metrics

Both features would modify the same core files (src/cli.ts and src/packager.ts), making this an ideal test case for Git's merge capabilities.

Setting Up Parallel Development

Creating Topic Branches

Starting from a clean main branch, I created two separate topic branches:

git checkout main
git checkout -b issue-12  # Verbose mode feature
git checkout main
git checkout -b issue-13  # Statistics enhancement

This approach follows the best practice of creating focused, single-purpose branches that can be developed independently.

Feature Implementation

Feature 1: Verbose Mode (issue-12 branch)

The verbose mode feature is required:

Adding a new CLI option (--verbose/-v)
Implementing detailed progress logging to stderr
Ensuring output doesn't interfere with main functionality

Example output:

Processing primary path: .
Processing path: .
Scanning directory: .
Found 8 files in directory: .
Processing 8 files...
Reading file: src/cli.ts
Reading file: src/packager.ts
...

Feature 2: Enhanced Statistics (issue-13 branch)

The statistics enhancement involved:

Extending the RepoInfo interface with new fields
Collecting additional metrics during file processing
Generating comprehensive summary output

Example output:

## Summary
- Total files: 10
- Total lines: 2254
- File types: .ts (6), .json (2), .md (2)
- Largest file: test-stats.md (575 lines)
- Average file size: 225 lines
- Total characters: 73,314
- Directories processed: 2

The Merge: Fast-Forward vs. Three-Way

First Merge: Fast-Forward Success

Merging the first feature (issue-12) back to main was seamless:

git checkout main
git merge issue-12

Result: Fast-forward merge! Since main hadn't changed since the branch was created, Git simply moved the main pointer forward to include the new commits.

Second Merge: Three-Way Recursive

The second merge (issue-13) was more interesting:

git merge issue-13

Result: Three-way recursive merge! Git automatically created a merge commit because main had diverged from the original branch point.

Conclusion

This parallel development exercise perfectly demonstrated Git's strength in managing concurrent development streams. The ability to work on multiple features simultaneously, then merge them seamlessly, is what makes Git an indispensable tool for software development.

The workflow taught me that:

Isolation enables innovation - Separate branches let you experiment fearlessly
Git handles complexity - Automatic merging works better than expected
Planning prevents problems - Thoughtful feature design reduces merge conflicts
Testing is crucial - Validating merged functionality ensures quality

Working with parallel branches isn't just a technical exercise—it's a fundamental skill that enables teams to work efficiently and deliver features faster. This hands-on experience has given me the confidence to tackle more complex branching scenarios in future projects.

Final commit hashes:

Verbose mode: e83e05f
Enhanced statistics: 2852691

The journey from parallel development to successful integration showcases Git's elegance in managing the complexity of modern software development. Every developer should master these workflows—they're not just tools, they're superpowers.

DEV Community: Tajudeen Abdulgafar

Taking Repo Context Packager to the Next Level

Introduction

The Plan: What I Will Do

1. Remote Repository Support

2. Security Redaction

3. Automating the Release Process (CI/CD)

4. Expanding Distribution

Why This Work Matters

The Approach

Conclusion

Implementing Authentication Middleware in Next.js with i18n Support

Introduction

Why Authentication Middleware?

Architecture Overview

Implementation Details

Authentication Check

Route Classification

Public Routes

Protected Routes

Protection Logic

Key Features

1. Automatic Route Protection

2. Smart Redirects

3. i18n Integration

4. Server Component Support

Best Practices

1. Secure Cookie Settings

2. Token Validation

3. Error Handling

4. Testing

Conclusion

Publish the repo-context-packager

Introduction

Executive Summary

Choosing the Release Tool and Package Registry

Why npm?

The Release Process: Step by Step

Step 1: Preparing package.json

Added bin Field

Added files Field

Updated main Field

Added postbuild Script

Step 2: Creating Practice Tags

Step 3: Building and Testing

Step 4: The First Publishing Attempt

Step 5: Version Bumping and Republishing

Step 6: Verifying Installation

Step 7: Creating the Release Tag

What I Learned:

Challenge 1: Package Name Conflicts

Challenge 2: Scoped Packages Are Private by Default

User Testing Session (Planned)

Lessons Learned

Future Improvements

Conclusion

NPM RELEASE

Building Confidence: CI, Local Tests

Introduction

Why Continuous Integration Was the Missing Piece

Executive Summary

Workflow Highlights

Leveling Up With Automated Testing

Introduction

Why Vitest?

Framework Setup

Building the Test Suite

Running Focused Tests (Step 4)

Optional Coverage

Lessons Learned

My Hacktoberfest 2025 Journey

Building a Frontend-Only Authentication System

Adding URL History to Integration Creation

Fixing Dark Mode Issues

Improved Theme System

Refactoring Journey: Improving Code Quality

Introduction

What I Focused On

1. Reducing Code Duplication

2. Improving Function Modularity

Added `bin` Field

Added `files` Field

Updated `main` Field

Added `postbuild` Script

Running Focused Tests (Step 4)

Step 1: Update `main`

Step 5: Merge Back to `main`