WAIT — Slowing — last commit 11mo ago

• Last commit 11mo ago
• Other licensed
• ⚠ Slowing — last commit 11mo ago
• ⚠ Solo or near-solo (1 contributor active in recent commits)
• ⚠ Non-standard license (Other) — review terms
• ⚠ No CI workflows detected
• ⚠ No test directory detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

Codelf is a web-based search tool that helps developers solve the variable naming problem by indexing real-world usage examples from GitHub, Bitbucket, Google Code, and other public repositories. It crawls open-source code to find how actual developers named variables, functions, and classes for specific use cases, then surfaces the most common patterns. The core offering is a search interface (web app + IDE plugins) that bridges the gap between a naming problem and battle-tested naming conventions used in production code. Monolithic single-app architecture: __static/app contains the entire web application with src/ holding the core JavaScript (App.js, Util.js, lib/), scss/ for styling (_main.scss, _bookmark.scss, _donate.scss), and html/ for template partials (main.html, sourcecode.html, components.html). The build system uses Gulp tasks to compile SCSS, transpile ES6+ with Babel, bundle with Webpack, minify, and serve with BrowserSync. Static resources (fonts, images, CSS libraries) are in resources/.

Full-stack JavaScript developers, frontend engineers, and IDE power users who struggle with naming decisions and want to see how real projects named similar entities. Secondary users are GitHub stars/repository organizers using Codelf's tagging and management features. Contributors would be Node.js developers comfortable with Gulp/Webpack build pipelines and SCSS styling.

Moderately mature and actively maintained: the project reached v8.1.0 with multiple IDE plugins (VS Code, Atom, Sublime) and a Chrome App distributed via official stores. The codebase is ~287K lines of JavaScript with organized Gulp/Webpack build infrastructure. However, no test suite is visible (package.json shows "test": "echo \"Error: no test specified\"") and last observed activity is assumed recent given the v8.1.0 version, but commit recency cannot be determined from the provided metadata.

Single maintainer (unbug) with no visible test coverage (tests explicitly missing) creates maintenance and regression risk. The project depends on 40+ dev dependencies (Babel 7, Webpack 4, Gulp 4) which may accumulate security patches. The architecture relies on crawling external code repositories which could be rate-limited or blocked. No CI/CD pipeline visible in the file list suggests manual release processes, increasing human error risk.

Cannot determine exact current work from provided metadata, but the project maintains active IDE plugin integrations (VS Code, Atom, Sublime listed with usage instructions) and offers a gh-pages deployment pipeline (npm run gh-pages). The presence of donation UI (_donate.scss, donate.html) and bookmark functionality (_bookmark.scss, bookmark.html) suggests ongoing feature maintenance alongside the core search functionality.

git clone https://github.com/unbug/codelf.git
cd codelf
npm install
npm start

The npm start command runs the default Gulp task (dev mode with BrowserSync), and npm run build creates a production build.

Daily commands:

npm start              # Dev mode with Gulp watch and BrowserSync (default task)
npm run build         # Production build (NODE_ENV=production)
npm run dist          # Full distribution build + gh-pages deployment prep

Dev server runs on a BrowserSync instance (typically http://localhost:3000); production output goes to a dist/ folder.

• __static/app/src/App.js — Main application entry point that orchestrates the MVC pattern and initializes the search tool UI and models.
• __static/app/src/model/SearchcodeModel.js — Core model that interfaces with searchcode API to fetch real-world variable name examples—the heart of the naming search functionality.
• __static/app/src/model/Database.js — Manages local database (lovefield) for caching search results and bookmarks—critical for offline functionality and performance.
• __static/app/src/view/View.js — Base view class implementing the MVC view layer, responsible for rendering results and handling user interactions.
• build-system/build.js — Build configuration orchestrating asset compilation, bundling, and distribution—required to understand the production pipeline.
• __static/app/src/AppBundle.js — Bundles and exports the application modules, serving as the interface between the build system and runtime components.
• __static/app/sw.js — Service Worker enabling offline functionality and caching strategy—essential for the app's progressive web app capabilities.

• SearchcodeModel (JavaScript, HTTP client, lovefield integration) — Queries searchcode.com API for variable names, implements retry/error handling, integrates with caching layer
  • Failure mode: API downtime or rate limiting returns cached results if available; degrades to local bookmarks only if cache empty
• Database (lovefield) (lovefield ORM, IndexedDB) — Persists search results, bookmarks, and user preferences in IndexedDB; handles query optimization and cache TTL
  • Failure mode: Browser storage quota exceeded prevents new caches; old entries evicted using LRU strategy
• View (MVC) (Bootstrap, jQuery, DOM API) — Renders search results, bookmark list, and translations; handles user interactions via jQuery event handlers
  • Failure mode: Missing results display gracefully with empty state; event handlers degrade if JavaScript disabled (but app requires JS)
• Service Worker (Service Worker API, Cache API, Fetch API) — Intercepts network requests, serves cached assets offline, manages cache lifecycle and updates
  • Failure mode: Old cache versions linger; strategy relies on manual cache versioning in manifest
• Build System — undefined

Add a new search data source

1. Create a new model file extending Model.js at __static/app/src/model/YourSourceModel.js (__static/app/src/model/Model.js)
2. Implement fetch() method to query your data source API (__static/app/src/model/YourSourceModel.js)
3. Register the model in App.js initialization (__static/app/src/App.js)
4. Add UI tab in __static/app/html/main.html to display results from your source (__static/app/html/main.html)

Add a new UI feature or tab

1. Create new HTML template in __static/app/html/yourfeature.html (__static/app/html/main.html)
2. Add styling rules in __static/app/scss/_yourfeature.scss (__static/app/scss/style.scss)
3. Create view class extending View.js at __static/app/src/view/YourFeatureView.js (__static/app/src/view/View.js)
4. Initialize view in App.js and wire events (__static/app/src/App.js)

Modify caching strategy

1. Update cache logic in Database.js for offline storage (__static/app/src/model/Database.js)
2. Update Service Worker caching strategy in sw.js (__static/app/sw.js)
3. Update manifest if adding new static assets to cache (__static/app/cache.manifest)

Add a new translation or language service

1. Create new model extending Model.js following YoudaoTranslateModel.js pattern (__static/app/src/model/YoudaoTranslateModel.js)
2. Implement API integration and caching in your new model file (__static/app/src/model/Database.js)
3. Register in App.js and wire to UI event handlers (__static/app/src/App.js)

• lovefield (local database) — Enables offline-first caching of search results and bookmarks without server dependency, essential for PWA functionality
• Service Worker (sw.js) — Provides offline support and intelligent caching of assets, allowing the tool to function without network connectivity
• MVC pattern (Model/View classes) — Separates concerns between data fetching, UI rendering, and business logic for maintainability and testability
• searchcode API integration — Primary data source providing real-world variable name examples from open-source projects across multiple platforms
• Babel + ESLint — Enables modern JavaScript syntax while maintaining code quality and consistency across the codebase

• Client-side caching with lovefield instead of server-side database

  • Why: Reduces server infrastructure costs and enables true offline functionality
  • Consequence: Cache data is per-device and not synced across user's devices; limited by browser storage quota (~50MB)

• Dependency on external searchcode.com API

  • Why: Avoids maintaining a massive indexed codebase and leverages existing searchcode infrastructure
  • Consequence: Tool functionality depends on third-party API availability; search speed limited by their rate limits

• No authentication/user accounts

  • Why: Simpler deployment and lower barrier to entry for users
  • Consequence: Bookmarks and preferences cannot be synced across devices; no collaborative features

• Real-time collaborative naming suggestions
• Private/enterprise codebase indexing
• IDE-agnostic solution (focused on web; VS Code extension is separate)
• Multi-language variable name normalization
• Machine learning-based naming recommendations

No explicit environment variables documented in the provided files, but the npm run gh-pages command assumes Git access to push to origin and subtree split capability (requires clean Git state). The app crawls external code repositories which may have rate limits or blocking—no API key management visible suggests queries may be public and subject to rate limiting. The project uses Gulp 4 which requires Node.js 10+ (implicit from Babel 7 config). Cache manifest (cache.manifest) indicates offline support, but invalidation logic is not obvious from the file list. No .env or configuration file visible—all external API endpoints are likely hardcoded in App.js.

• Web scraping & code indexing — Codelf's core value proposition is crawling and indexing real code from multiple Git hosting platforms (GitHub, Bitbucket, GitLab); understanding how variable names are extracted, normalized, and ranked from raw source code is essential
• Cross-origin requests (CORS) & browser APIs — The search appears to run in the browser (no visible backend), so it must handle CORS constraints when querying external repository APIs or use a proxy/backend service—critical for understanding why the app architecture is shaped as it is
• Offline-first web apps (Application Cache) — The presence of cache.manifest indicates the app uses HTML5 Application Cache for offline support—understanding cache invalidation and fallback strategies is relevant for app reliability
• Source map generation & Gulp asset pipeline — The build system (Gulp 4 + Webpack 4 + Babel) processes source files through multiple transformation steps with minification and optimization—understanding the pipeline is essential for debugging and adding new assets
• Plugin architecture for IDE integration — Codelf distributes as plugins across VS Code, Atom, and Sublime Text via different package ecosystems—understanding how a web tool exposes a unified interface to heterogeneous IDE extension APIs is architecturally interesting
• String similarity & fuzzy matching for variable names — Users search for variable names as natural language (e.g., 'user profile'), but need to match against actual camelCase or snake_case identifiers in source code—the ranking and matching algorithm behind results is non-obvious
• SCSS modular component styling — The SCSS architecture splits features into separate files (_main.scss, _bookmark.scss, _donate.scss, _components.scss) imported into style.scss—understanding this modular structure is key to maintaining the stylesheet as features grow

• shroudwagner/searchcode-app — searchcode is another code search engine for finding variable and function names in open source—direct competitor solving the same naming problem with a different backend approach
• karlll/search-code-ui — Alternative UI for code searching across repositories—offers similar real-world usage pattern discovery for naming decisions
• unbug/atom-codelf — Official Codelf integration for Atom editor—companion plugin extending this tool into the Atom IDE ecosystem (same maintainer)
• unbug/intellij-codelf — Official Codelf integration for IntelliJ IDEs (if it exists)—IDE plugin extending Codelf into the JetBrains ecosystem
• github/linguist — GitHub's language detection and code analysis library—Codelf likely uses similar language detection to filter search results by programming language

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add unit tests for SearchcodeModel.js and YoudaoTranslateModel.js

The repo has no test suite despite having a 'test' script in package.json. The model layer (__static/app/src/model/) is critical for API interactions with external services (searchcode and Youdao translate). Adding Jest or Mocha tests would catch regressions when refactoring these integrations and validate mock data handling.

• [ ] Install Jest/Mocha and testing utilities (e.g., jest, @testing-library/dom, nock for HTTP mocking)
• [ ] Create test files: __static/app/src/model/tests/SearchcodeModel.test.js and YoudaoTranslateModel.test.js
• [ ] Write tests covering API request formatting, response parsing, and error handling for both models
• [ ] Update package.json 'test' script to run Jest/Mocha instead of exiting with error
• [ ] Document test execution in README.md

Add GitHub Actions workflow for ESLint validation and build verification

The repo has ESLint configured (.eslintrc.js) but no CI pipeline. A GitHub Actions workflow would prevent merging PRs with linting errors or build failures. This is especially important given the build complexity (Babel, Webpack, Gulp, SCSS compilation).

• [ ] Create .github/workflows/ci.yml with jobs for: npm run lint (via gulp-eslint), npm run build, and NODE_ENV=production gulp build
• [ ] Add matrix strategy to test against Node 14+ LTS versions
• [ ] Configure workflow to trigger on push to main branches and all PRs
• [ ] Add status badge to README.md linking to Actions workflow

Document API integration and data flow for Model layer in CONTRIBUTING.md

The __static/app/src/model/ directory contains critical integrations (SearchcodeModel, DDMSModel, YoudaoTranslateModel, BookmarkModel) but their APIs, request/response formats, and usage are undocumented. New contributors cannot safely modify these without understanding the contracts.

• [ ] Create CONTRIBUTING.md with architecture overview of MVC pattern used (__static/app/src/model/, view/, lib/)
• [ ] Document each model's external API endpoints, authentication requirements, and expected response schemas
• [ ] Add sequence diagrams or examples showing: search query flow, bookmark persistence flow, and translation workflow
• [ ] Include instructions for running against staging/test versions of external APIs (searchcode.com, Youdao, GitHub)
• [ ] Reference this in README.md's contribution section

• Add a test suite: the package.json explicitly shows "test": "echo \"Error: no test specified\"" — create Jest or Mocha tests for __static/app/src/Util.js utility functions with realistic variable name transformations (camelCase, snake_case, kebab-case parsing)
• Document the search API integration: add comments and a separate docs file explaining which external APIs (GitHub, Bitbucket, Google Code, Sourceforge) are queried in __static/app/src/App.js and what the request/response structure looks like—currently opaque to new contributors
• Improve mobile responsiveness: review __static/app/scss/_main.scss and test on small screens; add specific mobile-first SCSS media queries since Fastclick is included but no clear mobile layout breakpoints are visible

• High · Outdated and Vulnerable Dependencies — package.json. Multiple dependencies have known vulnerabilities. Notable outdated packages include: node-sass (v4.13.0, deprecated and has security issues), webpack (v4.41.2, outdated), and babel packages (v7.7.4, outdated). These versions are from 2019-2020 and likely contain known CVEs. Fix: Update all dependencies to their latest stable versions. Run 'npm audit' to identify specific vulnerabilities and use 'npm update' or 'npm audit fix' to remediate. Consider using 'npm audit --audit-level=moderate' in CI/CD pipeline.
• Medium · Missing Content Security Policy Configuration — __static/app/index.html, __static/app/src/App.js. No Content Security Policy (CSP) headers are evident in the configuration. The application loads external resources (jQuery, Bootstrap, Tether, Lovefield, Prettify) and uses inline scripts, making it vulnerable to XSS attacks. Fix: Implement strict CSP headers in the server configuration. Define allowed sources for scripts, styles, and other resources. Example: 'Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline''
• Medium · Potential XSS Vulnerability in View Components — __static/app/src/view/View.js, __static/app/src/view/BookmarkView.js. The presence of View.js and BookmarkView.js files that manipulate DOM, combined with user-supplied search queries from external sources (searchcode, DDMS, Youdao), suggests potential XSS vulnerabilities if user input is not properly sanitized before rendering. Fix: Ensure all user input and data from external APIs is properly sanitized and escaped before DOM insertion. Use textContent instead of innerHTML where possible. Implement DOMPurify or similar library for HTML sanitization if dynamic HTML rendering is necessary.
• Medium · Third-party API Integration Without Rate Limiting or Validation — __static/app/src/model/SearchcodeModel.js, __static/app/src/model/YoudaoTranslateModel.js, __static/app/src/model/DDMSModel.js. The application integrates with multiple external APIs (searchcode, Youdao Translate, DDMS, GitHub) through Model classes without visible rate limiting, input validation, or error handling. This could expose the application to abuse or data extraction attacks. Fix: Implement rate limiting on API calls. Validate and sanitize all responses from external APIs. Add proper error handling and logging. Consider implementing API key rotation and using environment variables instead of hardcoding endpoints.
• Medium · Unencrypted Local Storage of Bookmarks — __static/app/src/model/BookmarkModel.js, __static/app/src/model/Database.js. The BookmarkModel uses Lovefield database (client-side) to store bookmarks without any encryption. Sensitive repository information or user data could be exposed if the browser storage is compromised. Fix: Encrypt sensitive data before storing in local storage. Use crypto libraries for client-side encryption, or implement a secure backend to store sensitive bookmarks. Consider implementing storage encryption with a user-provided key.
• Low · Missing Security Headers Configuration — Server configuration (not visible in provided files). No evidence of security headers (X-Frame-Options, X-Content-Type-Options, X-XSS-Protection, Strict-Transport-Security) in the codebase configuration. Fix: Configure security headers in your web server or CDN. Example headers: X-Frame-Options: DENY, X-Content-Type-Options: nosniff, X-XSS-Protection: 1; mode=block, Strict-Transport-Security: max-age=31536000; includeSubDomains
• Low · Service Worker Without Validation — __static/app/sw.js. A service worker (sw.js) is present but no cache validation or security measures are visible. This could allow serving stale or malicious cached content. Fix: Implement proper cache versioning and validation in the service worker. Use version hashing for assets. Implement a secure update mechanism. Validate cached content before serving.
• undefined · undefined — undefined. undefined Fix: undefined

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/unbug/codelf shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live unbug/codelf repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/unbug/codelf.

What it runs against: a local clone of unbug/codelf — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in unbug/codelf | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch master exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 367 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of unbug/codelf. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/unbug/codelf.git
#   cd codelf
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of unbug/codelf and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "unbug/codelf(\\.git)?\\b" \\
  && ok "origin remote is unbug/codelf" \\
  || miss "origin remote is not unbug/codelf (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(Other)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"Other\"" package.json 2>/dev/null) \\
  && ok "license is Other" \\
  || miss "license drift — was Other at generation time"

# 3. Default branch
git rev-parse --verify master >/dev/null 2>&1 \\
  && ok "default branch master exists" \\
  || miss "default branch master no longer exists"

# 4. Critical files exist
test -f "__static/app/src/App.js" \\
  && ok "__static/app/src/App.js" \\
  || miss "missing critical file: __static/app/src/App.js"
test -f "__static/app/src/model/SearchcodeModel.js" \\
  && ok "__static/app/src/model/SearchcodeModel.js" \\
  || miss "missing critical file: __static/app/src/model/SearchcodeModel.js"
test -f "__static/app/src/model/Database.js" \\
  && ok "__static/app/src/model/Database.js" \\
  || miss "missing critical file: __static/app/src/model/Database.js"
test -f "__static/app/src/view/View.js" \\
  && ok "__static/app/src/view/View.js" \\
  || miss "missing critical file: __static/app/src/view/View.js"
test -f "build-system/build.js" \\
  && ok "build-system/build.js" \\
  || miss "missing critical file: build-system/build.js"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 367 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~337d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/unbug/codelf"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.