WAIT — Stale — last commit 2y ago

• 3 active contributors
• Other licensed
• CI configured
• Tests present
• ⚠ Stale — last commit 2y ago
• ⚠ Small team — 3 contributors active in recent commits
• ⚠ Concentrated ownership — top contributor handles 68% of recent commits
• ⚠ Non-standard license (Other) — review terms

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

Mock.js is a JavaScript library that generates realistic simulated data and intercepts AJAX requests to provide complete request/response mocking without a backend. It uses template-based data generation with rules like @name, @email, @image to create diverse datasets for frontend development and automated testing. Monolithic structure: src/mock.js is the entry point; src/mock/ contains core modules (parser.js, handler.js, random/ subfolder with 10+ data generators like address.js, date.js, color.js). src/mock/xhr/ handles AJAX interception. Build outputs to dist/mock.js and minified variant via gulpfile.js.

Frontend developers and QA engineers who need to prototype UIs, develop features, or write tests before backend APIs are ready—particularly those using jQuery-based AJAX workflows who want to decouple frontend progress from backend availability.

Moderately mature but aging: version 1.0.1-beta3 with Travis CI/GitHub presence suggests active mid-2010s development, but the lack of visible recent commits and pre-release versioning indicates it may not be under active maintenance. Solid test infrastructure (mocha, phantomjs) and linting present, but no npm badge or coverage badge deployed suggests stalled momentum.

Low dependency risk (only commander.js as runtime dependency), but maintainer concentration risk is high—single author (nuysoft) and no visible contributor diversity. The pre-beta version number and refactoring branch in CI config suggest incomplete stabilization; AJAX mocking can be fragile across browser updates and modern frameworks (React, Vue, Angular) may not be primary targets.

Unknown from provided data—no commit log visible. The refactoring branch in .travis.yml suggests ongoing structural work, but maturity assessment indicates possible maintenance hiatus. No active PR or issue data provided.

git clone https://github.com/nuysoft/Mock.git
cd Mock
npm install
npm test

Daily commands:

npm test              # Run Mocha tests via Gulp
gulp connect          # Start local dev server (from gulpfile.js)
gulp                  # Build dist/mock.js (default Gulp task)

• src/mock.js — Main entry point that exports the Mock library and orchestrates all core functionality
• src/mock/schema/schema.js — Core schema parser that interprets data templates and generates mock data according to template rules
• src/mock/parser.js — Template parser that processes Mock.js syntax and converts it into executable generation logic
• src/mock/handler.js — Executes parsed templates and invokes random data generators to produce final mock values
• src/mock/random/index.js — Random data generation module index that provides all built-in generators for names, addresses, colors, dates, etc.
• src/mock/xhr/xhr.js — XHR/AJAX request interception layer that mocks HTTP responses based on registered routes

• Parser (src/mock/parser.js) (Regex-based lexing, recursive descent parsing) — Tokenizes and analyzes Mock.js template syntax (@name, @date, etc.) into an executable AST format
  • Failure mode: Invalid template syntax throws parse error; malformed patterns silently produce incorrect output
• Handler (src/mock/handler.js) (Recursive object construction, generator invocation) — Executes parsed AST nodes by invoking appropriate random generators and building the final mock object structure
  • Failure mode: Missing generator function throws error; insufficient entropy produces deterministic output
• Random Generators (src/mock/random/*) (Algorithmic generation, lookup tables, Math.random()) — Produces diverse, contextually appropriate random values (names, addresses, dates, colors, etc.)
  • Failure mode: Seeding not supported; repeated runs produce different data; quality depends on underlying algorithm
• XHR Interceptor (src/mock/xhr/xhr.js) (Prototype monkey-patching, route matching, Promise/callback handling) — Wraps XMLHttpRequest.prototype.open/send to intercept outgoing AJAX calls and return mock responses
  • Failure mode: Conflicts with other XHR wrappers (e.g., instrumentation libraries); breaks real network requests when routes registered
• Schema Engine (src/mock/schema/schema.js) (Recursive traversal, composition of parser + handler) — Combines parser and handler to convert full template objects into populated mock data structures
  • Failure mode: Deep nested templates

Add a new random data generator

1. Create new generator module in src/mock/random/ (e.g., src/mock/random/phone.js) exporting a function that returns random data (src/mock/random/phone.js)
2. Register the generator in src/mock/random/index.js by importing and assigning to the Random object (src/mock/random/index.js)
3. Add tests in test/test.mock.random.js to verify the generator works correctly (test/test.mock.random.js)

Add support for a new template syntax

1. Define the new syntax pattern in src/mock/constant.js (src/mock/constant.js)
2. Add parsing logic in src/mock/parser.js to recognize and tokenize the new syntax (src/mock/parser.js)
3. Add execution logic in src/mock/handler.js to process the parsed tokens and generate data (src/mock/handler.js)
4. Add tests in test/test.mock.schema.js to validate the new syntax behavior (test/test.mock.schema.js)

Add a new Mock.js API method

1. Add the method implementation in src/mock.js as a property of the Mock object (src/mock.js)
2. If the method requires a new module, create it in src/mock/ and import it in src/mock.js (src/mock.js)
3. Add corresponding tests in test/test.mock.mock.js (test/test.mock.mock.js)

• JavaScript (ES5) — Browser-compatible language allowing client-side data mocking without backend involvement
• XHR/AJAX Interception — Allows transparent mocking of HTTP requests without modifying application code that makes requests
• Regular Expression Support — Enables flexible pattern-based data generation for complex data types like phone numbers, emails, URLs
• Webpack + Gulp Build — Provides modular development workflow with transpilation, minification, and distribution bundling

• Client-side only interception vs server-side proxying

  • Why: Client-side interception simplifies deployment and avoids backend infrastructure requirements
  • Consequence: Only works in browser environments; cannot intercept requests from Node.js backends directly

• Template-based generation vs programmatic builders

  • Why: Template syntax is intuitive and requires no code; easy learning curve for non-programmers
  • Consequence: Less flexible for complex conditional logic; simpler but potentially slower than native code generation

• String-based template parsing vs JSON-only schemas

  • Why: String templates allow concise, readable syntax like @name, @date; more developer-friendly
  • Consequence: Requires parser implementation adding complexity; potential ambiguity in parsing edge cases

• Does not provide server-side mocking or backend API simulation
• Does not handle real-time data streaming or WebSocket mocking
• Does not replace actual backend testing or integration testing
• Does not provide request matching logic or route parameterization (focuses on data generation)
• Does not support database-backed mock data or persistent storage

No environment variables required, but be aware: (1) AJAX mocking relies on patching XMLHttpRequest globally—incompatible with modern fetch() API or frameworks using native HTTP clients (axios, fetch). (2) Webpack 1.12 is ancient; builds may fail on Node 14+. (3) Phantomjs is deprecated and unmaintained; test environment may break on new OS versions. (4) The bin/random CLI command depends on commander.js but has no visible documentation—run ./bin/random --help to discover usage.

• Template-based Data Generation — Mock.js's core pattern—understanding how @name and @image(200x100) syntax maps to generator functions in src/mock/parser.js is essential to extend the library with new data types.
• XMLHttpRequest Interception/Monkey Patching — The xhr module globally overrides native browser XMLHttpRequest to route AJAX calls to mock handlers—a fragile pattern that breaks with modern Fetch and service workers; critical to understand for debugging routing issues.
• Regular Expression-Based Parsing — The src/mock/regexp/ folder uses regex patterns (see RE_KEY.svg) to tokenize and validate template syntax; understanding regex matching is crucial for extending template grammar.
• Data Localization/Dictionaries — Files like src/mock/random/address_dict.js and src/mock/random/color_dict.js provide culturally/context-specific data pools; extending locale support requires understanding this dictionary pattern.
• Recursive Object/Array Template Expansion — Mock.js must recursively traverse nested object/array templates (e.g., { users: [{ name: '@name' }] }) to apply rules at all depths; this recursive handler logic in src/mock/handler.js is the heart of the engine.
• Seeded Pseudo-Random Number Generation — The src/mock/random/basic.js module provides seeded RNG for reproducible test data; critical for deterministic test runs despite randomness.

• faker-js/faker — Modern, actively maintained alternative for generating realistic fake data (names, addresses, emails) with similar template/rule-based approach but better docs and more data locales.
• miragejs/miragejs — Contemporary AJAX mocking library that handles both XMLHttpRequest and Fetch API, with built-in server simulation—solves the same problem as Mock.js's xhr module but for modern apps.
• json-schema-faker/json-schema-faker — Generates fake data from JSON Schema specifications rather than template strings—complementary approach for teams already using schema-driven development.
• bbyy199/mockjs2 — Community fork of Mock.js attempting to modernize and extend it with ES6+ support and new generators.
• mennovanslooten/mockJSON — Predecessor library that inspired Mock.js (cited in README)—simpler template-based approach that Mock.js built upon.

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 comprehensive unit tests for src/mock/regexp handler and parser

The regexp module (src/mock/regexp/handler.js and src/mock/regexp/parser.js) lacks dedicated test coverage. Currently test files focus on mock.js, random.js, and schema.js, but regexp pattern generation is critical for data simulation and has no corresponding test/test.mock.regexp.js file. This would improve reliability of regex-based mock data generation.

• [ ] Create test/test.mock.regexp.js with test cases for src/mock/regexp/parser.js pattern parsing
• [ ] Add test cases for src/mock/regexp/handler.js regex character generation (quantifiers, character classes, anchors)
• [ ] Add edge cases: escaped characters, nested groups, invalid patterns, and performance tests for complex regex
• [ ] Run gulp mocha to verify tests pass and maintain code coverage

Add unit tests for src/mock/valid validation module

While test/test.mock.valid.js exists, the validation logic in src/mock/valid/valid.js appears to be a core module for schema validation. The existing test file (test/valid.js and test/test.mock.valid.js) may have incomplete coverage of validation edge cases, data type checking, and error handling scenarios that are essential for reliable mock data generation.

• [ ] Audit test/test.mock.valid.js against all exported functions in src/mock/valid/index.js and src/mock/valid/valid.js
• [ ] Add missing test cases for complex nested object validation, circular reference handling, and type coercion
• [ ] Add integration tests combining valid.js with schema generation from src/mock/schema/
• [ ] Verify coverage reports meet >90% threshold for src/mock/valid/ directory

Add GitHub Actions workflow for Node.js compatibility matrix testing

The repo uses Travis CI (.travis.yml) which is now GitHub-owned. A GitHub Actions workflow would provide native CI/CD integration, better visibility, and allow testing against multiple Node.js versions (12, 14, 16, 18). This modernizes the build pipeline and ensures compatibility with various Node.js environments where Mock.js is used.

• [ ] Create .github/workflows/test.yml with matrix strategy for Node.js versions [12.x, 14.x, 16.x, 18.x]
• [ ] Configure jobs to run: npm install, npm run lint (via gulp jshint), npm test (via gulp mocha), and coverage reporting
• [ ] Add badge to README.md pointing to GitHub Actions workflow status
• [ ] Keep .travis.yml for backward compatibility or sunset it with a deprecation note

• Add Fetch API support alongside XMLHttpRequest interception in src/mock/xhr/xhr.js—currently only mocks AJAX, not modern fetch() calls.
• Write comprehensive tests for src/mock/random/text.js and src/mock/random/misc.js—these modules lack visible unit test coverage in the test/ directory.
• Add JSDoc comments to all exported functions in src/mock/random/*.js and update README.md with example usages for each generator type (address, date, color, name, web, image).

The Mock.js codebase has several security concerns primarily related to dependency management. The most critical issues are: (1) outdated and potentially vulnerable build tools (webpack 1.x, gulp 3.x), (2) overly permissive or outdated dependency versions lacking security patches, and (3) potential XSS risks in mock data generation without clear sanitization guidance. The project lacks modern security practices including dependency pinning, security documentation, and security header configuration. Immediate actions should focus on updating build dependencies, implementing npm audit in CI/CD, and documenting safe usage patterns for consuming applications.

• High · Overly Permissive Dependency Version — package.json - dependencies.commander. The 'commander' dependency uses '*' as its version specification, which allows any version including those with known vulnerabilities. This can lead to unexpected security issues when dependencies are installed. Fix: Pin the commander dependency to a specific known-safe version (e.g., '^3.0.0' or '^4.1.0') and regularly audit for vulnerabilities using npm audit.
• High · Unverified devDependency Versions — package.json - devDependencies (gulp-connect, gulp-coveralls, gulp-istanbul). Several devDependencies use loose version specifications (e.g., '^5.7.0' for gulp-connect) that could pull in minor/patch versions with vulnerabilities. gulp-connect@5.7.0 specifically has known security issues. Fix: Update to patched versions and audit regularly. Consider using 'npm audit' and 'npm ci' instead of 'npm install' for reproducible builds.
• Medium · Outdated Build Tools — package.json - devDependencies (webpack, gulp). The project uses webpack@1.12.9 and gulp@3.9.0, both of which are significantly outdated and may contain unpatched security vulnerabilities. Modern versions have important security fixes. Fix: Upgrade to current stable versions of webpack (5.x or later) and gulp (4.x or later) to receive security patches and modern tooling.
• Medium · XSS Risk in Simulation Data Generation — src/mock/random/text.js, src/mock/random/web.js. The codebase generates mock data including text, HTML content, and web data. Without proper sanitization, simulated data containing user input could be used unsafely in templates or DOM manipulation, leading to XSS vulnerabilities in consuming applications. Fix: Document that generated mock data should be treated as untrusted. Provide examples of safe usage with proper HTML escaping/sanitization in consuming code.
• Medium · Missing Security Headers in Development Server — gulpfile.js. The gulp-connect dev server configuration (if used for testing) may not include security headers like CSP, X-Frame-Options, or X-Content-Type-Options. Fix: Configure gulp-connect with security headers middleware or use a development server with built-in security headers. Never expose dev servers to production.
• Low · Executable Scripts Without Input Validation — bin/random. The bin/random executable may process command-line arguments without proper validation, potentially leading to injection attacks or unexpected behavior. Fix: Review and validate all command-line arguments. Use a library like 'commander' properly with strict argument parsing and validation.
• Low · No Security Policy Documentation — Repository root. No SECURITY.md file is present to document security practices, vulnerability reporting procedures, or security contact information. Fix: Create a SECURITY.md file following the GitHub security policy template to establish vulnerability reporting guidelines.

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/nuysoft/Mock 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 nuysoft/Mock repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/nuysoft/Mock.

What it runs against: a local clone of nuysoft/Mock — 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 nuysoft/Mock | Confirms the artifact applies here, not a fork | | 2 | License is still Other | Catches relicense before you depend on it | | 3 | Default branch refactoring exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 815 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of nuysoft/Mock. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/nuysoft/Mock.git
#   cd Mock
#
# 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 nuysoft/Mock and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "nuysoft/Mock(\\.git)?\\b" \\
  && ok "origin remote is nuysoft/Mock" \\
  || miss "origin remote is not nuysoft/Mock (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 refactoring >/dev/null 2>&1 \\
  && ok "default branch refactoring exists" \\
  || miss "default branch refactoring no longer exists"

# 4. Critical files exist
test -f "src/mock.js" \\
  && ok "src/mock.js" \\
  || miss "missing critical file: src/mock.js"
test -f "src/mock/schema/schema.js" \\
  && ok "src/mock/schema/schema.js" \\
  || miss "missing critical file: src/mock/schema/schema.js"
test -f "src/mock/parser.js" \\
  && ok "src/mock/parser.js" \\
  || miss "missing critical file: src/mock/parser.js"
test -f "src/mock/handler.js" \\
  && ok "src/mock/handler.js" \\
  || miss "missing critical file: src/mock/handler.js"
test -f "src/mock/random/index.js" \\
  && ok "src/mock/random/index.js" \\
  || miss "missing critical file: src/mock/random/index.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 815 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~785d)"
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/nuysoft/Mock"
  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.