Replace the Monolithic Constants File with an Auto-Discovery Plugin System for Tool Registration

[Suvam-paul145]

Problem Description

Currently, every tool must be manually registered in two separate files: app/libs/constants.tsx (which imports all 174+ component files and maps them in a single PATHS object) and app/libs/developmentToolsConstant.tsx (which stores metadata, SEO data, descriptions, and route information for each tool). The constants.tsx file alone is over 77 KB with 174 static imports at the top of the file. This architecture means that every time a new tool is added, the contributor must edit both files manually — if they forget one, the tool either does not render or has no metadata/route. Additionally, importing all 174 components eagerly in a single file defeats Next.js code splitting, potentially loading all tools into the initial JavaScript bundle.

Why It Is Required

This manual dual-registration pattern is the number one source of contributor errors and is fundamentally unscalable. As the project grows beyond 200+ tools, the constants files will become increasingly unmaintainable. The eager importing pattern also directly impacts the application's initial load performance — a new visitor downloading the JavaScript for all 174 tools when they only need one is wasteful. Replacing this with an auto-discovery or dynamic import system would make the codebase significantly easier to contribute to, reduce bugs, and improve performance through proper code splitting.

My Approach

I would refactor the tool registration system to use a convention-based auto-discovery approach. Each tool component would export its own metadata (slug, title, description, category) as a named export or a separate co-located metadata file (e.g., base64Encoder.meta.ts). A build-time script or Next.js dynamic import pattern would automatically discover all tools in the developmentToolsComponent/ directory and generate the routes and metadata registry. The PATHS object in constants.tsx would be replaced with next/dynamic imports, enabling proper code splitting. The developmentToolsConstant.tsx metadata would be generated from the co-located metadata files. This approach ensures that adding a new tool only requires creating a single directory with the component and its metadata — no manual edits to shared files.

I want to work on this issue.