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/askama-rs/askama-old 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.

WAIT — Stale — last commit 1y ago

• 17 active contributors
• Distributed ownership (top contributor 38% of recent commits)
• Apache-2.0 licensed
• Tests present
• ⚠ Stale — last commit 1y ago
• ⚠ No CI workflows detected

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

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

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

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

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

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

# 4. Critical files exist
test -f "askama_derive/src/lib.rs" \\
  && ok "askama_derive/src/lib.rs" \\
  || miss "missing critical file: askama_derive/src/lib.rs"
test -f "askama_parser/src/lib.rs" \\
  && ok "askama_parser/src/lib.rs" \\
  || miss "missing critical file: askama_parser/src/lib.rs"
test -f "askama_derive/src/generator.rs" \\
  && ok "askama_derive/src/generator.rs" \\
  || miss "missing critical file: askama_derive/src/generator.rs"
test -f "askama/src/lib.rs" \\
  && ok "askama/src/lib.rs" \\
  || miss "missing critical file: askama/src/lib.rs"
test -f "askama_escape/src/lib.rs" \\
  && ok "askama_escape/src/lib.rs" \\
  || miss "missing critical file: askama_escape/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 452 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~422d)"
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/askama-rs/askama-old"
  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).

Askama is a type-safe, compile-time template engine for Rust that generates optimized Rust code from Jinja2-like templates. It eliminates runtime template parsing by leveraging Rust's procedural macros (askama_derive) to validate and compile templates at build time, producing zero-cost abstractions with full type safety and IDE support. Monorepo structure: askama/ (core rendering engine with filters in src/filters/, error handling in src/error.rs), askama_derive/ (procedural macros for template compilation in src/lib.rs, config parsing, code generation, and inheritance resolution), and framework-specific integration crates (askama_actix/src/lib.rs, askama_axum/src/lib.rs, etc.) that provide type-safe responder implementations. Each integration crate includes templates/ and tests/ demonstrating usage.

Rust web developers building applications with Actix, Axum, Rocket, or Warp who need to render HTML templates without sacrificing type safety, performance, or compile-time guarantees. Particularly valuable for teams that want template errors caught before deployment.

This is an old archived repository (as stated in README); the project is actively maintained in the canonical fork at https://github.com/askama-rs/askama. The codebase shows significant maturity: 517KB of Rust code, comprehensive test suites in askama_derive/src/tests.rs, integration tests for multiple web frameworks (askama_actix, askama_axum, askama_rocket, askama_warp), and a structured monorepo with clear separation of concerns.

Critical: This is explicitly marked as an old/archived repository—all active development has moved to https://github.com/askama-rs/askama. Do not use this version for new projects. The workspace has 8+ member crates (askama, askama_derive, askama_actix, etc.) creating coupling between web framework support and core rendering logic, which can complicate maintenance. No recent commit data visible, confirming this is no longer the source of truth.

This repository is not actively maintained—it serves as a historical reference only. All development, bug fixes, and new features are happening at https://github.com/askama-rs/askama. Do not expect pull requests, issues, or commits here to be addressed.

Do not clone this repository for active development. Clone the current repository instead: git clone https://github.com/askama-rs/askama && cd askama && cargo build. If you must inspect this historical version: git clone https://github.com/askama-rs/askama-old && cd askama-old && cargo build.

Daily commands: In the historical (non-recommended) askama-old repo: cargo test runs the full test suite. Individual integration tests: cd askama_actix && cargo test or cd askama_axum && cargo test. Benchmark: cargo bench --manifest-path askama/benches/to-json.rs. Recommendation: Use the current repo at https://github.com/askama-rs/askama for any real work.

• askama_derive/src/lib.rs — Core procedural macro entry point that processes the #[derive(Template)] attribute and orchestrates template compilation.
• askama_parser/src/lib.rs — Template syntax parser that converts raw template strings into an AST; essential for understanding how templates are interpreted.
• askama_derive/src/generator.rs — Code generator that converts parsed AST into Rust source code; critical for understanding how templates become renderable structs.
• askama/src/lib.rs — Main library facade exposing the Template trait and filters; the public API all users depend on.
• askama_escape/src/lib.rs — HTML/XML escaping logic used throughout rendering to prevent injection attacks; foundational for security.
• askama_parser/src/expr.rs — Expression parser for template logic (conditionals, loops, variable interpolation); handles Rust expression evaluation in templates.
• askama_derive/src/input.rs — Configuration parsing for template attributes (path, delimiters, escaping mode); determines compile-time template behavior.

Add a new template filter

1. Define the filter function in the appropriate module inside askama/src/filters/ (askama/src/filters/mod.rs)
2. Export the filter via the filters module and ensure it accepts Display/AsRef<str> inputs (askama/src/filters/mod.rs)
3. The generator will automatically recognize filter calls in template syntax (e.g., {{ var|myfilter }}) and route to the filter function (askama_derive/src/generator.rs)
4. Add tests demonstrating the filter in action (askama_derive/src/tests.rs)

Add a new web framework integration

1. Create a new crate (askama_myframework/) mirroring the structure of askama_actix/ (askama_actix/src/lib.rs)
2. Implement the framework's response/responder trait for the Template type, calling .render() to get the string (askama_actix/src/lib.rs)
3. Set content-type to text/html and return the rendered output (askama_actix/src/lib.rs)
4. Add integration tests in tests/ directory to verify the responder works end-to-end (askama_actix/tests/basic.rs)

Modify template parsing rules

1. Update syntax rules in the parser (e.g., block delimiters, expression syntax) (askama_parser/src/lib.rs)
2. Add or modify node types if introducing new template constructs (e.g., custom loops) (askama_parser/src/node.rs)
3. Update the expression parser if the change affects variable/function syntax (askama_parser/src/expr.rs)
4. Update the code generator to emit appropriate Rust code for new node types (askama_derive/src/generator.rs)
5. Add parser tests and roundtrip tests to validate the new syntax (askama_parser/src/tests.rs)

Create a new template with inheritance

1. Create a base template file (e.g., base.html) in your templates directory and define {% block name %} sections (askama_derive/templates/a.html)
2. Create a child template that uses {% extends "base.html" %} and overrides specific blocks (askama_derive/templates/b.html)
3. The heritage resolver will automatically detect the inheritance chain at compile time (askama_derive/src/heritage.rs)
4. The generator will merge parent and child blocks when emitting Rust code (askama_derive/src/generator.rs)

• Procedural macros (syn, quote, proc-macro2) — Enables compile-time template compilation into Rust code, allowing full static type checking and zero runtime parsing overhead.
• Nom parser combinator library (in askama_parser) — Provides composable, efficient parsing for custom template syntax without writing manual state machines.
• HTML/XML escaping by default — Prevents XSS attacks by automatically escaping context-sensitive output; security-first design principle.
• Trait-based framework integration (Responder/IntoResponse) — Decouples template logic from web frameworks; allows multiple independent framework adapters without core changes.
• Template inheritance via extends/blocks — Enables DRY template composition; resolved at compile time with zero runtime cost.

• Compile-time template processing via macros instead of runtime template engines

  • Why: Eliminates file I/O, parsing, and interpretation at runtime; enables full Rust type checking and IDE support.
  • Consequence: Templates must be valid at compile time; any template syntax error fails the build. Dynamic template loading not supported.

• Eager escaping by default (HTML mode) rather than opt-in

  • Why: Prevents XSS vulnerabilities by making security the default behavior.
  • Consequence: Users must explicitly mark safe content with |safe filter, adding verbosity for intentionally raw HTML.

• Parser and generator separated into distinct crates (askama_parser vs askama_derive)

  • Why: Allows reuse of parser by external tools; cleaner dependency tree.
  • Consequence: Requires synchronization between parser AST changes and generator expectations.

• Filters implemented as Rust functions rather than plugins

  • Why: Leverages Rust's type system and compiler; no runtime reflection or dynamic loading.
  • Consequence: Adding filters requires modifying source code; no end-user-defined filters at runtime.

• Runtime template loading or hot-reloading
• Dynamic/user-defined template syntax extensions
• Template caching or memoization (delegated to web frameworks)
• Client-side or JavaScript template support
• Non-HTML template modes beyond escaping toggles

This is archived—the biggest trap is using this repo instead of https://github.com/askama-rs/askama. If examining this code: (1) Template paths in #[template(path = "...")] are relative to the crate's root, not src/; (2) Procedural macros in askama_derive must be compiled before askama can be built, hence the workspace ordering; (3) Web framework integrations (askama_actix, askama_axum) require their respective framework crates as dependencies—pulling just askama won't work with Actix; (4) The to-json benchmark (askama/benches/to-json.rs) assumes serde_json is available; (5) Filter function signatures in askama/src/filters/ use Rust's Display trait, so custom filters must implement it.

• Procedural Macros (derive macros) — Askama's entire compilation strategy relies on the #[derive(Template)] macro to generate render code at compile time; understanding syn/quote is essential to modifying code generation
• Type-safe template rendering — Askama's core promise is that template errors are caught at compile time as Rust type mismatches; this requires understanding how template variables are mapped to Rust types
• Template inheritance and block overrides — Managed in askama_derive/src/heritage.rs, this mechanism (inspired by Jinja2 blocks) allows base templates to define slots filled by child templates; critical for DRY template design
• Responder trait pattern — Web framework integrations (askama_actix/src/lib.rs, askama_axum/src/lib.rs) implement framework-specific Responder/IntoResponse traits; this is how templates become HTTP responses
• Zero-cost abstractions via code generation — Askama generates optimized Rust code instead of interpreting templates at runtime; understanding the generated output in askama_derive/src/generator.rs reveals performance characteristics
• Jinja2 template syntax and semantics — Askama templates use Jinja2-compatible syntax (loops, conditionals, filters, macros); contributors need to know Jinja2 to add language features
• Escape strategies (auto-escaping vs raw output) — askama/src/filters/ implements context-aware escaping; understanding when HTML/JavaScript escaping is applied prevents XSS vulnerabilities in rendered templates

• tera-rs/tera — Alternative Rust template engine with Jinja2-like syntax and runtime evaluation; solves the same problem but with dynamic (not compile-time) rendering
• djc/askama — The current active repository for Askama—all development has moved here; this archive is superseded
• actix/actix-web — Web framework for which Askama provides first-class template integration via askama_actix responder
• tokio-rs/axum — Modern modular web framework; Askama integrates via askama_axum providing type-safe response rendering
• rouille/rouille — Lightweight Rust web framework; demonstrates the broader ecosystem of web frameworks that Askama supports

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 tests for askama_parser benchmarks and edge cases

The askama_parser/benches/librustdoc directory exists but appears incomplete. The parser is a critical component for the entire Askama ecosystem. Adding structured unit tests for edge cases (unclosed tags, nested expressions, malformed syntax) would prevent regressions and improve robustness. This is high-value because parser bugs cascade across all dependent crates (askama_derive, askama_actix, askama_axum, etc.).

• [ ] Review askama_parser/src/lib.rs to identify parser functions lacking test coverage
• [ ] Create askama_parser/src/tests.rs with test cases for: malformed templates, deeply nested blocks, edge cases in expression parsing, and unicode handling
• [ ] Add integration tests in askama_parser/tests/ that validate parser output against known-good AST structures
• [ ] Document test categories in askama_parser/README.md

Add missing integration tests for askama_escape edge cases and unsafe scenarios

The askama_escape crate has benches/all.rs but minimal visibility into test coverage for security-critical escaping scenarios. Since this handles HTML/JavaScript/URL escaping, missing tests for: double-encoding, mixed content types, and context-switching could lead to XSS vulnerabilities. High-value for security-conscious projects.

• [ ] Examine askama_escape/src/lib.rs to identify all escape functions (html, js, url, etc.)
• [ ] Create askama_escape/tests/security.rs with test cases for: attribute context, script context, URL context, and mixed encoding scenarios
• [ ] Add property-based tests using proptest in askama_escape/tests/ to validate escaping is idempotent and doesn't double-escape
• [ ] Document escaping guarantees in askama_escape/README.md

Create missing integration test suite for askama_derive template resolution and inheritance

The askama_derive/src/heritage.rs file handles template inheritance, but askama_derive/tests/ appears to only have basic.rs. Template path resolution, circular dependency detection, and multi-level inheritance (a.html → b.html → c.html chain in askama_derive/templates/) need comprehensive tests. High-value because template inheritance bugs break production rendering.

• [ ] Review askama_derive/src/heritage.rs and askama_derive/src/config.rs to understand path resolution logic
• [ ] Create askama_derive/tests/inheritance.rs with tests for: circular template inheritance, missing template paths, multi-level inheritance chains using the existing template files
• [ ] Add askama_derive/tests/path_resolution.rs to test template discovery with custom path configurations
• [ ] Document expected behavior in askama_derive/README.md regarding path resolution edge cases

• The askama_escape crate is listed in Cargo.toml but has no src/ directory visible in the file list—this crate may be incomplete or needs documentation. A contributor could add a src/lib.rs with HTML/XML escaping utilities and comprehensive tests.
• askama_parser is referenced in workspace but not shown in the file structure—a contributor could document or implement the parser module that tokenizes template syntax (currently this logic may be inlined or missing).
• The testing/ crate is listed as a default member but has no visible source—someone could establish a shared test utilities module with helper macros for template compilation and comparison.

This is an archived/deprecated Askama repository redirecting to the current project. The static analysis reveals moderate security posture. Primary concerns include: (1) potential XSS risks in template filters without full filter code visibility, (2) macro-based code generation that could be vulnerable to template path injection, and (3) the repository's deprecated status creating migration risks. The codebase appears well-structured with separate security-sensitive modules (filters, escape, parser), but without access to full implementation details and dependency versions, a comprehensive assessment is limited. No obvious hardcoded secrets, exposed credentials, or Docker misconfigurations were detected in the file structure provided. Recommend using the current repository and running standard Rust security tooling (cargo audit, clippy with security lints).

• Medium · Potential XSS Vulnerability in Template Rendering — askama/src/filters/mod.rs, askama/src/filters/json.rs. Askama is a template engine that generates Rust code from templates. Without explicit analysis of all filter implementations (particularly in askama/src/filters/), there is a risk that user-provided data could be rendered without proper escaping in certain contexts. The presence of filters and HTML template files suggests HTML output, which requires careful escaping. Fix: Review all custom filters to ensure they properly escape output for their respective contexts (HTML, JSON, URL, etc.). Verify that the default filter behavior includes auto-escaping for HTML contexts. Document escape behavior clearly.
• Medium · Macro-Based Code Generation Security — askama_derive/src/lib.rs, askama_derive/src/generator.rs, askama_derive/src/config.rs. The askama_derive crate uses procedural macros to generate code from template files. If user-controlled template paths or contents can be injected without validation, this could lead to code generation attacks. The macro processes template files at compile time, which could be exploited if template directories are not properly secured. Fix: Validate and sanitize all template paths and names. Ensure template directories are not world-writable. Document the security model for template loading. Consider implementing a whitelist of allowed template locations.
• Low · Deprecated/Archived Repository Status — README.md, repository root. The README explicitly states this is an old/archived repository and directs users to the current repository at https://github.com/askama-rs/askama. Users may be using outdated versions with unpatched security issues if they rely on this repository. Fix: Ensure all users migrate to the current repository. Consider archiving this repository on GitHub to prevent accidental usage. Add prominent deprecation warnings in all documentation.
• Low · Missing Dependency Vulnerability Analysis — Cargo.toml and all subcrate Cargo.toml files. The Cargo.toml workspace file is present but specific dependency versions are not visible in the provided content. Without access to full Cargo.lock or detailed Cargo.toml files for each crate, transitive dependencies cannot be assessed for known vulnerabilities. Fix: Run 'cargo audit' regularly in CI/CD to detect known vulnerabilities in dependencies. Pin versions appropriately and use 'cargo update' cautiously. Subscribe to security advisories for all direct dependencies.
• Low · Multiple License Files Without Verification — LICENSE-APACHE, LICENSE-MIT files throughout. Each crate contains both Apache 2.0 and MIT license files. While permissive, there is no visible license compliance automation or verification in the provided file structure. Fix: Implement license scanning in CI/CD pipeline using tools like cargo-deny or license-maven-plugin. Document license compatibility for all dependencies.

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.