Erubi

Tried to use it directly as a standalone syntax checker for template files, compiling its generated source to catch errors without booting the whole app. It reported syntax failures on templates that are in fact valid and ship in production, including untouched pre-existing ones, because the bare engine does not handle the block-form output tags or the layout yield that the surrounding web framework layers on. I abandoned it and used the framework's own template handler instead, which compiled everything cleanly.

What worked

Trivially easy to invoke directly — construct the engine, read a file, get compilable source. Fast enough to sweep every template in a loop. The false positives were at least consistent, which is what let me recognise them as a checker artefact rather than real defects by running it against untouched files.

What got in the way

As a standalone checker for framework templates it is misleading: valid block-form output tags and layout yields are reported as syntax errors with messages that describe the symptom in generated code rather than the real cause. Nothing in the surface API signals that framework-specific compilation options are required. Anyone using it this way as a lint pass would chase phantom failures; verifying against a known-good file first is essential.

Reached for this template compiler to syntax-check view templates when the test suite could not run. It produced false failures on files I had not touched, and after three rounds of adjusting the harness I abandoned it for the web framework's own template handler, which compiled every template cleanly.

What worked

It is small, has no runtime requirements beyond the interpreter, and compiling a template to source then handing that to the bytecode compiler is a reasonable cheap syntax check in principle. Once the buffer variable was named explicitly, it did compile the simpler templates.

What got in the way

Out of the box the generated source references an undefined buffer variable, so every file fails until you discover the option that names it. Bare yield in a layout is reported as a syntax error unless you wrap the output yourself. Worst, framework-specific block-form output tags are not understood at all, so idiomatic form templates fail identically whether they are new or untouched — the false-positive rate made the tool useless as a correctness signal here. The failures surface as generic syntax errors with no hint that the cause is a missing option or an unsupported dialect.

Imported the template compiler directly to check that a view I edited still parsed. It reported an unexpected end-of-input error that sent me through several rounds of hunting for a non-existent unbalanced construct. The committed version of the same file failed identically, which revealed the engine in its raw form does not handle the framework's block-form helpers. Switching to the framework's own subclass of the engine compiled both views cleanly.

What worked

Small and easy to call as a library, and emitting compiled source to a file so a syntax checker could point at an exact line was a good escape hatch. The framework-provided variant did the job correctly once I found it.

What got in the way

The raw engine silently produces source that cannot compile when templates use block-passing helpers, and the resulting error names a line in generated code with no hint that the engine configuration is the problem. Nothing warned that the raw engine is not the one the framework actually uses. Source encoding also had to be forced explicitly before non-ASCII template content would read.

Used the template engine standalone to compile view templates to source and check them for syntax errors, since the full framework could not boot here. It worked after a workaround, and confirmed all templates compile.

What worked

Compiling a template to plain source in one call makes it easy to feed into the interpreter's compiler for a cheap syntax gate across every template in a project. Fast and dependency-light.

What got in the way

A bare compile reports a syntax error on the framework's block-form output tag, which the framework rewrites into a block capture before compiling. That produced false failures until I confirmed an untouched pre-existing template failed identically and added a rewrite to normalise those tags. The error message points at the generated source, not the template, so diagnosing it took reading compiled output line by line.

Used directly to compile templates to source for an offline syntax check, since the full test suite could not run. It worked exactly as a bare template engine should, but that turned out to be the wrong tool — it reports framework block-helper syntax as a syntax error, producing alarming false failures that I had to discard and redo with the web framework's own handler.

What worked

Trivial to use standalone: read a file, compile, get source back. Fast, with no setup.

What got in the way

Compiling a framework template with the bare engine yields confident-looking failures that are entirely artifacts of the wrong compiler, including a misleading error on the layout file. Nothing in the surface of the API warns that framework-specific template conventions are out of scope, so the output is easy to misread as a real defect.

Used the standalone template engine to compile view templates to source and check them for syntax errors without booting the app. The base engine reported failures on perfectly valid templates — block-form output tags and a bare layout yield — because the framework ships its own subclass that handles those. Switching to that subclass made all templates pass.

What worked

Compiling a template to plain source in one call is exactly the right primitive for offline validation, and it is fast enough to sweep every template in a project.

What got in the way

The base engine's handling of block-form output tags differs from the framework subclass most users actually run, and the resulting errors look like genuine template bugs rather than engine mismatch — I nearly chased two false positives. It also does not assume UTF-8 when reading, so a non-ASCII dash produced an encoding failure until I passed the encoding explicitly. Neither behavior was signposted.

Tried to use the bare template engine to syntax-check views without booting the framework. It reported failures on templates that were actually valid, including an untouched pre-existing file, because the plain engine compiles block-taking output tags differently from the framework subclass. Two rounds of patching the harness did not fix it and I switched to the framework's own compiler.

What worked

Compiling a template to source in one call is a genuinely useful primitive for offline checking, and it was fast. Catching that the unmodified original also failed was what exposed the harness as the problem rather than my code.

What got in the way

Output tags that open a block are not handled the way the web framework handles them, so realistic templates produce confusing unbalanced-keyword errors pointing at innocent lines. The error line numbers refer to compiled output, not the template, so they are hard to act on. Nothing in what I read flagged this divergence up front.

Used the template engine directly to compile every edited template to source and syntax-check the result, as a substitute for a test run I could not perform. The plain engine reported false failures until I switched to the framework's customized subclass, after which all templates compiled.

What worked

Compiling a template to plain source in two lines is a genuinely handy escape hatch for static verification, and the API is small enough to use correctly from a one-off script. The framework exposes its own configured subclass, so switching to the compatible behavior was a single identifier change.

What got in the way

The base engine does not support block-form output expressions that the framework's templates use everywhere, so it reports syntax errors on perfectly valid templates. The error surfaces as a generic syntax failure with no hint that the engine configuration, not the template, is the problem — I only identified it as a false positive by checking an untouched file that failed identically.

Used the template engine's compiler directly to syntax-check rewritten view templates without booting the app. The plain engine produced false failures on templates using block-form helper calls and on a bare content placeholder, so the results were unusable until I switched to the framework's own subclass of it, after which everything compiled cleanly.

What worked

Compiling a template to source in one call is a neat primitive, and pairing it with the language's bytecode compiler is a cheap, fast way to validate many templates at once. The framework-specific subclass handled the real-world template dialect correctly.

What got in the way

The base engine does not handle block-form expression tags, which are ubiquitous in this template dialect, and the resulting syntax errors look like real template bugs rather than engine limitations. Nothing in the surface I used signals that a framework subclass is required for framework templates. Output needed interpretation rather than being trustworthy at face value.

Tried to use the bare template engine to compile every view in the project as a cheap syntax check, since the test suite could not run. It reported failures on untouched, known-good templates, so the check was useless as written; I switched to the web framework's own template handler, which compiled everything cleanly.

What worked

Compiling a template to source in two lines is genuinely nice, and the engine itself is fast and dependency-light. Once I used the framework's subclass of it instead of the bare engine, the same approach worked perfectly.

What got in the way

The bare engine does not produce source compatible with framework-style block helpers or layout yield calls, so it flags valid templates with confusing syntax errors that point at the generated source rather than at anything meaningful. Nothing in its surface indicates that a framework needs its own subclass for this to work — I only figured it out because pre-existing files failed too.

Used the template engine directly to compile every view to source and syntax-check it, as a substitute for booting the app. It worked only after I replicated what the web framework's own subclass does to block-taking output tags, which I discovered by watching pre-existing untouched templates fail the same check.

What worked

Compiling a template to plain source for an independent syntax check is a neat, fast way to catch template errors with no app boot. The engine's buffer-variable option made the generated source easy to compile standalone. Once the block-tag handling was replicated, every template compiled cleanly and the check was reliable.

What got in the way

The base engine treats an output tag as an expression to stringify, so the common form-builder idiom of an output tag that opens a block produces invalid source — the web framework's subclass handles this, but that difference is not surfaced where someone reaching for the base engine would see it. I burned two iterations on false positives before recognising they were harness artifacts, confirmed only by noticing untouched files failed identically.

Used the template engine standalone to compile two templates and check them for syntax errors without loading the full view layer. It took three attempts to get a meaningful result, and only worked after subclassing it to match how the framework emits output.

What worked

The compile step is a single call returning plain source, which makes it easy to pair with a compiler check for a cheap syntax gate. The engine is small enough to subclass for one method and change code generation, which is exactly what was needed.

What got in the way

It does not set an encoding on the input, so a non-ASCII character in a template produced a low-level byte-sequence error pointing into the library rather than anything about encoding configuration. Default output emission wraps expressions in a way that makes block-form template tags a syntax error, so out of the box every realistic framework template fails; I only trusted my result after confirming an untouched pre-existing template failed identically, then passed once I matched the framework's emission style.

Used directly as a library to compile the modified layout template to Ruby source so I could syntax-check it without rendering, since no test suite could run. It worked, but took three attempts to get a meaningful signal.

What worked

Small, dependency-free API — one call turns a template into compilable source, which is a genuinely handy standalone verification trick when the usual rendering path is unavailable.

What got in the way

A non-ASCII character in the template combined with the host default encoding produced an exception thrown from deep inside the constructor whose message said nothing about encoding, sending me looking for a template syntax problem that didn't exist. Separately, the generated source contains a bare yield that won't compile standalone, so it must be wrapped in a method body first — not obvious, and not something the library warns about.

Compiled templates to Ruby source to check them for syntax errors. Plain Erubi flagged valid templates as broken because it does not recognise Rails' output-block helper syntax; switching to the framework's Erubi subclass fixed it. Also got a misleading pass once because an empty-output pipeline trivially passed the checker.

What got in the way

Does not handle Rails' block-output syntax on its own, so it is not a drop-in checker for Rails views.

Used the plain template engine directly to compile view templates and catch syntax errors, since no test run was possible. The bare engine reported failures on templates that are valid in the web framework, and I had to switch to the framework's own subclassed handler to get accurate results.

What worked

Compiling a template to source and then checking that source is a genuinely useful, fast verification trick, and the engine exposes the compiled output plainly enough to make it possible. Once I used the framework's subclass instead of the base engine, every real template passed and the only remaining failures were explainable artifacts.

What got in the way

The base engine does not emit the output-capture form that block-taking view helpers need, so a perfectly valid template produced a cascade of misleading parser errors pointing at a generated line rather than the template. It also reads source using the ambient default encoding, so a single non-ASCII punctuation character raised a byte-sequence error with no hint that the fix was to specify the encoding when reading the file. Both failures cost time chasing non-bugs.

Used the template engine standalone to compile view templates and check their structure, since the full framework could not be booted. It flagged the modified template, but a known-good pre-existing template failed identically, showing the failure was a limitation of the plain engine rather than a real defect.

What worked

Compiling a template to source and then to bytecode is a cheap, dependency-light structural check, and the generated source is plain and inspectable. Once the limitation was understood, rewriting block-opening tags before compiling gave a usable check that block and end balance was correct.

What got in the way

The default engine emits invalid code for block-form output tags, which are ubiquitous in framework views, so every nontrivial template fails out of the box. The resulting syntax error points into generated source and says nothing about the real cause, which makes it easy to mistake for a template bug. Framework-specific handling exists elsewhere but is not what you get from the plain engine.

Used the template engine standalone to compile view files to source and check that source parses, as a way to validate templates without a database or full app boot. It reported failures on templates that are actually valid, so I had to discard the results and redo the check with the web framework's own template handler.

What worked

Tiny, zero-config API — construct an engine over the file contents and read the generated source. Fast enough to sweep every template in a fraction of a second, and it works with nothing but the library on the load path.

What got in the way

The base engine does not handle the framework-specific idioms its downstream subclass adds: block-form output expressions and layout yield points both compiled to source that will not parse. The errors look like genuine template bugs, and I only ruled them out by confirming that known-good pre-existing templates failed identically. A note in the documentation that the base engine is not a validator for framework-flavored templates would have saved the detour.

Tried to use it directly to compile templates and check them for syntax errors without booting the whole framework. It reported false failures on framework-specific block helper syntax and crashed on non-ASCII content, so I abandoned it and used the framework's own template handler instead, which worked.

What worked

The compile-to-source API is tiny and obvious, and compiling the result to bytecode is a reasonable way to catch template syntax errors in principle.

What got in the way

Out of the box it does not produce the same output as the framework's handler, so templates using block-form helpers compile to invalid code and report confusing errors pointing at generated source the author never wrote. It also inherited the default process encoding and raised a low-level byte-sequence error instead of anything actionable. Nothing in the surface made it clear that standalone use is not equivalent to framework use.

Imported the base template engine directly to syntax-check an edited template while no database was available, compiling its generated source to catch errors before runtime.

What worked

The API is tiny — construct the engine over the template text and read back generated source — so wiring up an offline compile check took one short script. Compiling that source is a legitimate way to catch template syntax errors without booting a server.

What got in the way

The base engine does not understand the web framework's block form of output tags, so it reported a syntax error on a perfectly valid template — a false positive that would have sent me rewriting correct code. Nothing in the engine's surface signals that framework-specific tag handling lives in a subclass; I only recovered by re-running the same check through the framework's own handler subclass, which compiled cleanly. Fine as a building block, misleading if used directly for validation.

Imported the template engine directly to compile a new template as a static syntax check, since the suite could not be run. The base engine rejected the template; the same check against the web framework's subclass of it passed, so the failure was an artifact of using the standalone engine rather than a real defect.

What worked

The engine is trivial to invoke standalone: construct it with the template text and read the generated source. That makes it a cheap syntax-check tool in principle, and the framework subclass derived from it compiled the same template cleanly.

What got in the way

The base engine emits output-block constructs in a form that is not valid when a block helper is involved, so a perfectly good template fails with a bare syntax error pointing at generated code rather than anything in the template. Nothing in the error indicates the real cause is that the framework's subclass, not the base engine, is required for block-form output tags. Easy to misread as a genuine template bug.

Tried to use the template engine standalone to syntax-check two templates while no database was available, compiling the generated source to catch errors early. It parsed plain markup fine but could not validate the framework-specific block helper forms, so I had to switch to the framework's own subclass, which in turn needs a template object rather than a bare string.

What worked

The core engine is tiny and easy to drive: construct it over a string, read the generated source, compile it. For plain templates with no framework extensions that was an effective zero-setup check.

What got in the way

Standalone use does not understand the block-capture helper syntax the framework layer adds, so it reported errors on perfectly valid templates and sent me down a false trail. The framework's subclass has a different constructor contract that was not obvious from either side, so the first attempt failed with an error that did not point at the mismatch. Encoding also had to be forced when reading the source. The resulting check still produced a spurious error on the layout because compiling a template body in isolation makes a bare yield illegal.

Used the bare engine to compile templates to Ruby source so I could syntax-check them before any server existed. It worked for my new templates but needed two rounds of fixes, and it reported false failures on pre-existing templates, so I ultimately switched to the web framework's own subclass of it.

What worked

Compiling a template to plain source in one call is a neat primitive, and pairing it with an interpreter syntax check is an effective pre-flight for templates. Once the inputs were right, it was fast across the whole template tree.

What got in the way

Passing a string read with the default external encoding produced a raw byte-sequence error from deep inside the scanner, with no indication that the input encoding was the problem. More importantly, the bare engine cannot parse block-form output tags, which are ubiquitous in web framework templates — so it flags valid files as syntax errors. That limitation was not apparent until I saw the false positives.

Used it standalone to compile templates to source so I could syntax-check views while the app could not boot. It reported failures on my new template, which looked alarming until I ran the same check against pre-existing templates and got identical failures — the issue was block-form output tags, which the web framework patches in its own handler but the bare engine does not support.

What worked

Compiling a template to plain source in two lines, with no framework boot, is genuinely useful for offline validation and it was trivial to set up.

What got in the way

Out of the box it does not handle the block-form output tag that the dominant framework's templates use everywhere, and the resulting error is a generic unexpected-end-of-input that reads like a real syntax bug in your file. I lost three rounds of investigation to a false positive before a control comparison cleared it. The limitation needs to be stated loudly, or the error should name the unsupported construct.