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/Auburn/FastNoiseLite 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.

GO — Healthy across the board

• Last commit 3mo ago
• 25+ active contributors
• MIT licensed
• CI configured
• Tests present
• ⚠ Concentrated ownership — top contributor handles 63% of recent commits

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

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

What it runs against: a local clone of Auburn/FastNoiseLite — 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 Auburn/FastNoiseLite | Confirms the artifact applies here, not a fork | | 2 | License is still MIT | 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 ≤ 114 days ago | Catches sudden abandonment since generation |

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

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

# 2. License matches what RepoPilot saw
(grep -qiE "^(MIT)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"MIT\"" package.json 2>/dev/null) \\
  && ok "license is MIT" \\
  || miss "license drift — was MIT 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 "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "Cpp/FastNoiseLite.h" \\
  && ok "Cpp/FastNoiseLite.h" \\
  || miss "missing critical file: Cpp/FastNoiseLite.h"
test -f "JavaScript/src/FastNoiseLite.ts" \\
  && ok "JavaScript/src/FastNoiseLite.ts" \\
  || miss "missing critical file: JavaScript/src/FastNoiseLite.ts"
test -f "C/FastNoiseLite.h" \\
  && ok "C/FastNoiseLite.h" \\
  || miss "missing critical file: C/FastNoiseLite.h"
test -f "Rust/src/lib.rs" \\
  && ok "Rust/src/lib.rs" \\
  || miss "missing critical file: Rust/src/lib.rs"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 114 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~84d)"
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/Auburn/FastNoiseLite"
  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).

FastNoise Lite is a highly portable, single-header noise generation library implementing OpenSimplex2, Perlin, Cellular (Voronoi), and Value noise algorithms with support for 2D/3D sampling and domain warping. It solves the problem of needing performant, cross-language noise generation without platform dependencies, shipping implementations in 19+ languages from C++ to PowerShell, each compiled/transpiled from a reference algorithm. Monorepo structure: language-specific directories (Cpp/, CSharp/, Java/, JavaScript/, Rust/, GLSL/, HLSL/, etc.) each contain self-contained implementations; JavaScript/src/FastNoiseLite.ts is the TypeScript source, compiled to JavaScript/dist/ via tsc. WebPreviewApp/ provides a visual testing/demo tool. Each language has a README.md explaining usage and any quirks.

Game developers, graphics programmers, and procedural generation researchers who need noise for terrain generation, texture synthesis, or heightmaps and want to use the same algorithm across C++, C#, GLSL shaders, Rust, JavaScript/TypeScript, and other target platforms without rewriting core logic.

Actively maintained and production-ready. It's an evolution of the original FastNoise library (see FastNoise-Legacy branch), has published releases on npm and crates.io (v1.1.1 current), includes CI workflows for multi-language publishing (deploy-web-preview-app.yml, publish-js.yml, publish-rust.yml), and maintains a web preview app at https://auburn.github.io/FastNoiseLite. Test coverage exists (JavaScript/test/FastNoiseLite.test.ts), indicating active quality control.

Low risk for stability but medium risk for adoption decisions: it's intentionally feature-light (simple, portable reference implementations) compared to FastNoise2 which offers SIMD performance and node graphs. Single maintainer (Jordan Peck, Patrick U) means PR review speed depends on availability. Breaking changes are unlikely given the stable API across 19 language ports, but the project explicitly recommends FastNoise2 for 'more extensive' use cases, suggesting this repo has defined scope boundaries.

Active CI/CD: workflows publish JavaScript to npm (publish-js.yml), Rust to crates.io (publish-rust.yml), and auto-deploy the web preview app. TypeScript v5.8.3 builds are current. No visible ongoing feature work in file list suggests stable maintenance mode with focus on reliable multi-language release cadence.

Clone and build the JavaScript/TypeScript implementation: git clone https://github.com/Auburn/FastNoiseLite.git && cd FastNoiseLite/JavaScript && npm install && npm run build. The built output appears in JavaScript/dist/. To test: npm test.

Daily commands: JavaScript: npm run build compiles TypeScript in JavaScript/src/ to JavaScript/dist/. To run tests: npm test (uses Node.js with experimental type-stripping flags). Web preview app is built separately and deployed to GitHub Pages (see .github/workflows/deploy-web-preview-app.yml). No local dev server command visible in package.json; web app likely built via separate toolchain.

• README.md — Entry point documenting the library's purpose, features, and multi-language support strategy—essential for understanding the project's scope and design philosophy
• Cpp/FastNoiseLite.h — The canonical C++ reference implementation that serves as the source of truth for all language ports; all other implementations derive from this
• JavaScript/src/FastNoiseLite.ts — The TypeScript source for the JavaScript port with build output in dist/, demonstrating the modern build pipeline and language-specific optimizations
• C/FastNoiseLite.h — The minimal C header implementation showing the most portable version of the API, critical for understanding zero-dependency constraints
• Rust/src/lib.rs — The Rust port illustrating how the noise algorithms are adapted to idiomatic Rust with Cargo dependency management
• Java/FastNoiseLite.java — The Java port demonstrating object-oriented translation of the functional noise generation API for JVM adoption
• JavaScript/package.json — Defines the npm publication strategy, versioning, and build/test scripts for the JavaScript ecosystem distribution

Port FastNoise Lite to a new language

1. Start by reading the Cpp/FastNoiseLite.h header as the canonical algorithm reference (Cpp/FastNoiseLite.h)
2. Create a new directory under the repo root (e.g., MyLanguage/) and implement the class/module following the same public API shape as Cpp/FastNoiseLite.h (MyLanguage/FastNoiseLite.ml)
3. Add a README.md to your language directory documenting usage examples and any language-specific dependencies or considerations (MyLanguage/README.md)
4. If your language has a package manager (npm, crates.io, etc.), create configuration files (e.g., package.json, Cargo.toml) and set up CI/CD in .github/workflows/ to auto-publish releases

Update the JavaScript/TypeScript implementation

1. Edit the TypeScript source file to add or modify noise generation methods (JavaScript/src/FastNoiseLite.ts)
2. Run 'npm run build' to compile TypeScript into dist/FastNoiseLite.js and generate dist/FastNoiseLite.d.ts type definitions (JavaScript/tsconfig.json)
3. Add test cases to verify correctness across noise types and parameters (JavaScript/test/FastNoiseLite.test.ts)
4. Run 'npm test' to verify all tests pass before committing

Add GPU shader support for a new graphics API

1. Use GLSL/FastNoiseLite.glsl as the algorithmic template and adapt it to your target shader language (e.g., Metal, WebGPU) (GLSL/FastNoiseLite.glsl)
2. Create a new directory (e.g., WebGPU/) and write the shader implementation following the same uniform/varying patterns (WebGPU/FastNoiseLite.wgsl)
3. Document performance characteristics and any shader-specific limitations in a README (WebGPU/README.md)

Release a new version across all ecosystems

1. Update version numbers in JavaScript/package.json and Rust/Cargo.toml with the new semantic version (JavaScript/package.json)
2. Commit and tag the release (e.g., 'git tag v1.2.0') on the master branch (README.md)
3. Push the tag to trigger GitHub Actions workflows in .github/workflows/, which auto-publish to npm (JavaScript) and crates.io (Rust) (.github/workflows/publish-js.yml)

• C/C++ reference implementations — Provides canonical algorithm definitions that are language-agnostic, portable, and serve as the source-of-truth for all 13+ language ports
• TypeScript + npm ecosystem — Enables browser and Node.js adoption with type safety, modern build tooling, and automatic CI/CD publishing to npm via GitHub Actions
• GLSL/HLSL shaders — Allows real-time GPU-accelerated noise generation for graphics pipelines, critical for game engines and visual effects
• Multi-language ports (Rust, Go, Java, etc.) — Maximizes adoption across ecosystems by providing idiomatic implementations that respect language conventions (e.g., Rust's safety, Go's concurrency, Java's OOP)
• GitHub Actions workflows — Automates testing and publishing across npm and crates.io, reducing manual release overhead and ensuring version consistency

• Single canonical C++ header vs. monolithic library

  • Why: Simplicity and portability—no external dependencies, easy to integrate into any project
  • Consequence: All logic must fit in headers; harder to maintain complex optimizations, but achieves zero-dependency portability

• Maintain 13+ language ports in a single repo

  • Why: Centralized algorithm updates and consistency across ecosystems
  • Consequence: Increased maintenance burden; slower to respond to language-specific feature requests; requires multi-language expertise on maintainers

• Prioritize algorithm correctness over platform-specific SIMD optimizations

  • Why: Ensure identical noise output across all languages (determinism for procedural generation)
  • Consequence: Cannot leverage hardware-specific vectorization; delegated to FastNoise2 for extreme performance

• Compile TypeScript to JavaScript rather than ship TypeScript directly

  • Why: Broader browser compatibility and smaller bundle sizes for Node.js users
  • Consequence: Requires build step; source maps needed for debugging; slightly slower for TypeScript-native projects

• Real-time 3D mesh generation or GPU compute kernels (see FastNoise2 for SIMD acceleration)
• Platform-specific audio or physics integrations
• Distributed or network-based noise generation
• Machine learning training or tensor operations
• Interactive UI beyond the web preview demo app

No hidden traps obvious from file list. Each language implementation is self-contained with no external runtime dependencies. JavaScript build requires TypeScript 5.8.3+ (specified in devDependencies). The web preview app (source not visible in top 60 files — likely in WebPreviewApp/ directory not shown) is deployed via GitHub Actions and may require a separate build step not documented in main package.json. No env vars, auth tokens, or service dependencies apparent in package.json or .github workflows.

• OpenSimplex2 noise — Core noise algorithm in this library, a modern improvement over original Simplex noise with fewer artifacts; understanding its design is essential for porting or extending FastNoise Lite.
• Domain warping — Advanced feature mentioned in README that distorts noise space for complex effects (e.g., turbulent terrain); used in games for more organic procedural generation.
• Fractional Brownian Motion (FBM) — Multi-language fractal option listed in features; essential for natural-looking terrain and clouds by layering noise at multiple scales.
• Cellular/Voronoi noise — Distinct algorithm in FastNoise Lite producing cell-like patterns useful for cave systems, cracks, and biological textures.
• Language transpilation / code generation — The FastNoise Lite project architecture: a single reference algorithm ported to 19 languages with minimal platform-specific code. Maintaining correctness across ports is the core engineering challenge.
• Shader implementation (GLSL/HLSL) — GPU variants allow noise generation on graphics cards without CPU-GPU transfer, critical for real-time effects; GLSL/FastNoiseLite.glsl and HLSL/FastNoiseLite.hlsl are drop-in shader replacements.
• Deterministic pseudorandom number generation — Noise functions must produce identical output for identical inputs across all language implementations; no randomness, only deterministic math enables reproducible procedural generation.

• Auburn/FastNoise2 — Official successor library with SIMD performance and node-graph architecture; users outgrowing FastNoise Lite's feature set are directed here.
• Auburn/NoiseBenchmarking — Reference benchmarking suite used to measure FastNoise Lite C++ performance; linked in README and essential for validating algorithm optimizations.
• Rust-Gamedev/wg-noise — Rust game development working group's noise ecosystem; fastnoise-lite is published as a crate and competes with/complements other Rust noise libraries.
• BinomialLLC/basis_universal — Texture encoding library often paired with procedural noise for game asset generation; users generating terrain textures with FastNoise often compress results with Basis.
• perlin-noise/perlin-noise — Alternative Perlin noise implementation in Rust/JavaScript; FastNoise Lite Perlin mode provides a well-optimized competitor.

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 C/FastNoiseLite.h with CI validation

The C implementation lacks visible test coverage compared to JavaScript (which has FastNoiseLite.test.ts). C is a critical language for this library given its portability focus. Adding unit tests with a GitHub Actions workflow would ensure the C implementation maintains parity with other language ports and prevent regressions.

• [ ] Create C/test directory with test suite using a C testing framework (e.g., Unity, cmocka, or Criterion)
• [ ] Write tests covering all noise types (Simplex, OpenSimplex2, Perlin, Cellular, Value) with basic validation
• [ ] Add GitHub Actions workflow (.github/workflows/test-c.yml) to compile and run C tests on push/PR
• [ ] Verify tests validate output ranges and basic noise generation correctness
• [ ] Document test setup in C/README.md with build instructions

Add GitHub Actions workflow for Golang tests and verify fastnoise.go implementation

The Go implementation (Go/fastnoise.go) exists but there's no visible CI coverage for it (publish-rust.yml and publish-js.yml exist, but not Go). Given Go's importance in cloud/infrastructure projects, adding automated tests would ensure quality and encourage Go adoption.

• [ ] Create Go/fastnoise_test.go with unit tests covering all exported functions and noise types
• [ ] Add GitHub Actions workflow (.github/workflows/test-go.yml) to run 'go test' and 'go build' on push/PR
• [ ] Verify cross-platform builds (Linux, macOS, Windows) in the workflow
• [ ] Update Go/README.md with testing instructions and import examples
• [ ] Ensure go.mod dependencies are documented and tested

Add cross-language validation tests to verify algorithmic parity across implementations

With implementations in 10+ languages, there's risk of subtle algorithmic divergence. The repo lacks integration tests comparing outputs across languages (e.g., C++ vs C vs JavaScript vs Rust for identical inputs). This would catch porting bugs early and build confidence in language equivalence.

• [ ] Create a test suite (e.g., tests/cross-language-validation/) that generates reference noise output from C++ implementation with known seeds/coordinates
• [ ] Write scripts to compare outputs from JavaScript (JavaScript/test), Rust, C, Java, and Go implementations against the reference
• [ ] Add GitHub Actions workflow (.github/workflows/validate-cross-language.yml) to run comparisons on push/PR
• [ ] Document acceptable tolerance levels for floating-point differences in tests/README.md
• [ ] Use the WebPreviewApp's existing test patterns as reference for generating consistent test data

• Add property-based tests to JavaScript/test/FastNoiseLite.test.ts using a QuickCheck-style library: Current test file name suggests basic tests exist; property-based tests would validate algorithm invariants (e.g., output range bounds, determinism) across random input spaces without manually written cases.
• Port OpenSimplex2 domain warp to HLSL and GLSL variants if missing: Feature list mentions domain warp but HLSL/FastNoiseLite.hlsl and GLSL/FastNoiseLite.glsl files are present; verify completeness and add any missing fractal/warp modes that C++ and JavaScript already support.
• Create a TypeScript-based test/benchmark suite comparing noise output across all language implementations: No visible cross-language validation; a Node.js script that imports JavaScript version, compares results against C++ reference via WASM bindings (if built), would catch translation bugs early.

FastNoiseLite is a well-maintained noise generation library with a strong security posture. The codebase shows no critical vulnerabilities, SQL injection risks, XSS vulnerabilities, hardcoded secrets, or exposed infrastructure issues. The primary concerns are minor dependency management practices and the use of experimental Node.js features in testing. The library's focus on algorithm implementation rather than web services or data handling significantly reduces the attack surface. Recommended actions include updating dependency pinning strategies, adding a SECURITY.md file for vulnerability reporting, and monitoring experimental feature stability in Node.js.

• Medium · Outdated TypeScript Dependency — JavaScript/package.json - devDependencies.typescript. TypeScript version 5.8.3 is relatively recent but should be monitored for security updates. The caret (^) version specifier allows automatic minor/patch updates which could introduce breaking changes or security issues. Fix: Regularly update TypeScript to the latest stable version. Consider using npm audit to check for vulnerabilities in the dependency tree. Pin to specific versions for production builds if stability is critical.
• Low · Experimental Node.js Features in Test Script — JavaScript/package.json - scripts.test. The test script uses experimental Node.js features (--experimental-strip-types and --experimental-transform-types). These features may change or be removed in future Node.js versions, causing test failures and potential compatibility issues. Fix: Monitor Node.js releases and be prepared to update the test command when these experimental features are stabilized or replaced. Document the minimum Node.js version required for running tests.
• Low · Missing SECURITY.md File — Repository root. The repository lacks a SECURITY.md file that defines vulnerability reporting procedures. This makes it difficult for security researchers to responsibly report vulnerabilities. Fix: Create a SECURITY.md file that includes instructions for responsible disclosure, security contact information, and how to report vulnerabilities privately.
• Low · Broad DevDependency Pinning — JavaScript/package.json - devDependencies.@types/node. The @types/node dependency uses a caret version (^22.15.3), allowing automatic updates that could include breaking changes in minor versions. This affects development environment consistency across team members. Fix: Consider using tilde (~) or exact version pinning for @types/node to ensure consistent development environments. Use npm ci instead of npm install for deterministic builds.

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

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

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