@ape-egg/vibe 2.3.0 → 3.0.0

package/compiler/src/Cargo.toml

@@ -1,38 +0,0 @@
-[package]
-name = "vibe-compiler"
-version = "2.2.0"
-edition = "2021"
-description = "Vibe framework compiler - compiles Vibe source files into optimized output"
-authors = ["Kim Korte"]
-license = "ISC"
-
-[[bin]]
-name = "vibe-compiler"
-path = "main.rs"
-
-[dependencies]
-clap = { version = "4.4", features = ["derive"] }
-serde = { version = "=1.0.210", features = ["derive"] }
-serde_json = "1.0"
-html5ever = "0.27"
-markup5ever_rcdom = "0.3"
-markup5ever = "0.12"
-thiserror = "1.0"
-regex = "1.10"
-colored = "2.1"
-ureq = { version = "2", features = ["tls"] }
-glob = "0.3"
-rquickjs = "0.6"
-swc_common = "=0.40.1"
-swc_ecma_parser = "=0.152.0"
-swc_ecma_ast = "=0.121.0"
-swc_ecma_visit = "=0.107.0"
-notify = "6.1"
-notify-debouncer-full = "0.3"
-rayon = "1.10"
-
-[profile.release]
-opt-level = 3
-lto = true
-codegen-units = 1
-strip = true

package/compiler/src/compiler/PRE-RENDERING-IMPLEMENTATION.md

@@ -1,241 +0,0 @@
-# Pre-Rendering Implementation: swc, QuickJS, and Manifest Restoration
-
-## Overview
-
-This document describes how pre-rendering works in Vibe's compiler, the technical challenges encountered, and the solutions implemented. The goal is to pre-render HTML with actual state values (FOUC prevention) while preserving markers for runtime reactivity.
-
-## Technologies Used
-
-### swc (JavaScript AST Parser)
-- **Purpose**: Parse JavaScript code to extract state variables and resolve imports
-- **Use Case**: When HTML contains `import { menuSections } from '/index.js'`, we need to know what variables exist
-- **Implementation**: `js_analyzer.rs` - traverses AST to find import declarations and build scope
-
-### QuickJS (JavaScript Runtime)
-- **Purpose**: Execute JavaScript to evaluate state values for pre-rendering
-- **Use Case**: Transform `@[firstName]` → `"John"` by evaluating the state object
-- **Implementation**: `value_stamper.rs` - creates JS context with state, evaluates expressions
-
-## The Pre-Rendering Flow
-
-```
-1. Parse HTML → 2. Extract State → 3. Build Manifest → 4. Stamp Values
-   (html5ever)      (swc + QuickJS)     (before stamping)    (QuickJS)
-```
-
-**Critical**: Manifest must be built BEFORE value stamping, otherwise templates contain pre-rendered values instead of markers.
-
-## Problems Encountered and Solutions
-
-### Problem 1: Manifest Build Order
-**Symptom**: Manifest templates contained `"Vibe Compiled"` instead of `@[section.label]`
-
-**Root Cause**: Manifest was being built AFTER value stamping:
-```rust
-// WRONG ORDER (old code)
-let pre_rendered = stamper.stamp_html(html.to_string())?;
-let manifest = manifest_builder.build_from_html(&pre_rendered, &state, iterations_as_is)?;
-```
-
-**Solution**: Reorder operations - build manifest first:
-```rust
-// CORRECT ORDER (compile.rs lines 556-565)
-let state = StateExtractor::extract_from_html(html, &source_root.to_path_buf())?;
-let manifest = manifest_builder.build_from_html(html, &state, iterations_as_is)?;
-let pre_rendered = stamper.stamp_html(html.to_string())?;
-```
-
-**Files Modified**: `compile.rs`
-
----
-
-### Problem 2: Multiline Script Tag Parsing
-**Symptom**: State extraction logged "found 0-length scripts"
-
-**Root Cause**: Regex didn't match newlines in multiline `<script>` blocks:
-```rust
-// WRONG (old code)
-let script_regex = Regex::new(r#"<script[^>]*>(.*?)</script>"#).unwrap();
-```
-
-**Solution**: Add `(?s)` flag to make `.` match newlines:
-```rust
-// CORRECT (state_extractor.rs line 22)
-let script_regex = Regex::new(r#"(?s)<script[^>]*>(.*?)</script>"#).unwrap();
-```
-
-**Files Modified**: `state_extractor.rs`
-
----
-
-### Problem 3: Invalid Name Binding HTML Syntax
-**Symptom**: Elements inserted via `insertBefore()` but immediately disappeared from DOM
-
-**Root Cause**: html5ever serializer normalized name bindings to invalid HTML:
-- Input: `<icon @[section.icon]>`
-- html5ever output: `<icon @[section.icon]="">`
-- Browsers reject attributes with dynamic names followed by `=""`
-
-**Solution**: Post-process serialized HTML to strip `=""` from name bindings:
-```rust
-// manifest_builder.rs (serialize_nodes function)
-let name_binding_fix = Regex::new(r#"(@\[[^\]]+\])="+"#).unwrap();
-html = name_binding_fix.replace_all(&html, "$1").to_string();
-```
-
-**Shortcut Taken**: This is a post-processing hack rather than fixing html5ever's serialization logic. It works for standard cases but could theoretically fail if there are edge cases with quotes inside bindings.
-
-**Files Modified**: `manifest_builder.rs`
-
----
-
-### Problem 4: Wrong Iteration Comment Matching
-**Symptom**: Restoration found nested `<!-- each section.items as item -->` instead of target `<!-- each menuSections as section -->`
-
-**Root Cause**: Searched for first `<!-- each -->` comment without specificity
-
-**Solution**: Store and match the exact iteration expression:
-```rust
-// manifest_builder.rs (lines 142-161)
-if trimmed.starts_with("each ") {
-    let expression = trimmed.strip_prefix("each ").unwrap_or("").to_string();
-    // ... store expression in RestorationData
-}
-```
-
-```javascript
-// pre-compiled-manifest.js
-const expectedComment = `each ${restoration.expression}`;
-if (trimmed === expectedComment && !startComment) {
-    startComment = comment;
-}
-```
-
-**Files Modified**: `manifest_builder.rs`, `pre-compiled-manifest.js`
-
----
-
-### Problem 5: Wrong End Comment - Nested Iteration Depth (THE CRITICAL FIX)
-**Symptom**:
-- Menu rendered 25 times (5 × 5) instead of 5
-- Restoration found wrong parent: `ACCORDION-CONTENT` instead of correct parent
-- Console showed duplicate conditional comments
-
-**Root Cause**:
-HTML structure has nested iterations:
-```html
-<!-- each menuSections as section -->  (line 57)
-  <nav-section>
-    <accordion>
-      <!-- each section.items as item -->
-        ...
-      <!-- /each -->  (line 98 - closes section.items, NOT menuSections!)
-    </accordion>
-  </nav-section>
-  <!-- 4 more nav-sections with their own nested iterations -->
-<!-- /each -->  (line 483 - actually closes menuSections)
-```
-
-The restoration code found the correct start comment but matched the FIRST `<!-- /each -->` (line 98), which closed a nested iteration. This caused:
-1. Only removing the first nav-section (5 items total, leaving 4 = 20 items)
-2. Inserting template 5 times (once per menuSection)
-3. Each insertion added 5 items = 25 total
-
-**Solution**: Track nesting depth and only match `/each` at depth 0:
-```javascript
-// pre-compiled-manifest.js
-let depth = 0;
-const walker = document.createTreeWalker(element, NodeFilter.SHOW_COMMENT);
-while (walker.nextNode()) {
-    const comment = walker.currentNode;
-    const trimmed = comment.textContent.trim();
-
-    if (trimmed === expectedComment && !startComment) {
-        startComment = comment;
-        depth = 1; // We're now inside this iteration
-    } else if (startComment) {
-        if (trimmed.startsWith('each ')) {
-            depth++; // Entering nested iteration
-        } else if (trimmed === '/each') {
-            depth--; // Exiting an iteration
-            if (depth === 0) {
-                endComment = comment; // This closes OUR iteration
-                break;
-            }
-        }
-    }
-}
-```
-
-**Why This Works**:
-- `depth = 1` when we enter `menuSections`
-- `depth = 2` when we enter nested `section.items`
-- `depth = 1` when we exit nested `section.items` (line 98)
-- `depth = 0` when we exit `menuSections` (line 483) - **this is our match**
-
-**Files Modified**: `pre-compiled-manifest.js`
-
----
-
-## Edge Cases and Limitations
-
-### Known Shortcuts
-1. **Name binding fix**: Post-processing regex instead of proper html5ever configuration
-2. **Comment parsing**: Assumes comments are well-formed (no nested comments in strings)
-
-### Will This Work for Most Cases?
-**Yes**, the solution is robust for standard use cases:
-
-✅ **Works For**:
-- Nested iterations at any depth
-- Multiple iterations at the same level
-- Conditionals inside iterations
-- Iterations inside conditionals
-- Mixed nesting patterns
-
-⚠️ **Edge Cases**:
-- Identical iteration expressions at multiple nesting levels (e.g., `<!-- each items as item -->` appears twice in nested structure)
-  - Solution: Expression matching will find the first one, depth tracking ensures correct pairing
-  - This is acceptable because the outer iteration would have a different parent element
-
-- Comments inside JavaScript strings that look like iteration comments
-  - Example: `const x = "<!-- each items as item -->"` in a `<script>` tag
-  - This would confuse the comment walker
-  - Mitigation: Unlikely in practice, as state is extracted separately
-
-- Name bindings with quotes inside: `<icon @[items["key"]]>`
-  - The regex fix might not handle all quote variations
-  - Mitigation: Rare in practice, typically use dot notation
-
-### Future Improvements
-1. **Proper html5ever integration**: Configure serializer to not add `=""` for dynamic attributes
-2. **AST-based comment parsing**: Use html5ever's comment nodes instead of regex/text matching
-3. **Unique iteration IDs**: Generate unique IDs for each iteration during compilation, use those for matching instead of expressions
-
-## Testing Checklist
-When modifying this code, verify:
-- [ ] Simple iterations render correctly
-- [ ] Nested iterations (2+ levels deep) render correctly
-- [ ] Multiple iterations at same level render correctly
-- [ ] Pre-rendered HTML shows actual values (no FOUC)
-- [ ] Runtime finds markers and makes content reactive
-- [ ] Menu navigation works (indicates correct event handlers)
-- [ ] Console shows no errors during restoration
-
-## File Summary
-
-| File | Purpose | Key Changes |
-|------|---------|-------------|
-| `compile.rs` | Main compilation orchestration | Reordered manifest build before value stamping |
-| `state_extractor.rs` | Extract state from `<script>` tags | Fixed multiline regex with `(?s)` flag |
-| `manifest_builder.rs` | Build restoration manifest | Added expression field, fixed name binding serialization |
-| `pre-compiled-manifest.js` | Runtime restoration logic | Added expression matching and depth tracking |
-
-## Conclusion
-
-The pre-rendering system now correctly handles nested iterations by:
-1. Storing iteration expressions for precise matching
-2. Tracking depth to find the correct closing comment
-3. Building manifests before value stamping to preserve markers
-
-The depth tracking solution is the critical piece that makes nested iterations work correctly. Without it, the restoration would match the wrong closing comment and corrupt the DOM structure.

package/compiler/src/compiler/binding_case.rs

@@ -1,88 +0,0 @@
-use regex::Regex;
-use std::collections::HashMap;
-use std::sync::OnceLock;
-
-/// The canonical `@[...]` binding matcher, shared with manifest_builder /
-/// value_stamper. A binding body is any run of non-bracket chars, optionally
-/// containing a single bracketed group (`items[0]`).
-fn binding_regex() -> &'static Regex {
-    static RE: OnceLock<Regex> = OnceLock::new();
-    RE.get_or_init(|| Regex::new(r"@\[((?:[^\[\]]|\[[^\]]*\])+)\]").unwrap())
-}
-
-/// html5ever lowercases attribute NAMES per the HTML spec. A name-binding lives
-/// in attribute-name position (`<icon @[selectedEquipProps(uuid).element]>`), so
-/// its expression is lowercased by every parse/serialize round-trip — the
-/// identifier `selectedEquipProps` becomes `selectedequipprops`, undefined at
-/// runtime. Attribute VALUES keep their case, so value-bindings are unaffected.
-///
-/// We can't tell html5ever to preserve case, so we restore it ourselves: snapshot
-/// the original-cased `@[...]` bindings from the input BEFORE the round-trip, then
-/// map them back over the output AFTER. The map is keyed by the lowercased binding
-/// (what the round-trip produces) → original binding.
-///
-/// First-wins on a lowercase collision (two differently-cased bindings that
-/// lowercase to the same key): rare, and either casing is a defensible restore.
-pub fn capture(input: &str) -> HashMap<String, String> {
-    let mut map = HashMap::new();
-    for caps in binding_regex().captures_iter(input) {
-        let original = caps.get(0).unwrap().as_str();
-        let lower = original.to_ascii_lowercase();
-        if lower != original {
-            map.entry(lower).or_insert_with(|| original.to_string());
-        }
-    }
-    map
-}
-
-/// Restore original casing of `@[...]` bindings in `output` using a map built by
-/// [`capture`]. Only bindings whose lowercased form is a known key are rewritten;
-/// everything else is left verbatim, so this is a no-op when nothing was lowered.
-pub fn restore(output: &str, map: &HashMap<String, String>) -> String {
-    if map.is_empty() {
-        return output.to_string();
-    }
-    binding_regex()
-        .replace_all(output, |caps: &regex::Captures| {
-            let matched = caps.get(0).unwrap().as_str();
-            match map.get(&matched.to_ascii_lowercase()) {
-                Some(original) => original.clone(),
-                None => matched.to_string(),
-            }
-        })
-        .to_string()
-}
-
-#[cfg(test)]
-mod tests {
-    use super::*;
-
-    #[test]
-    fn restores_lowercased_name_binding() {
-        // Post-prop-substitution name binding (parens added by substitute_props),
-        // as it enters an html5ever round-trip. html5ever lowercases the whole
-        // attr name; restore puts the original casing back.
-        let input = "<icon @[(selectedEquipProps(uuid)).element]></icon>";
-        let map = capture(input);
-        let lowered = "<icon @[(selectedequipprops(uuid)).element]></icon>";
-        let restored = restore(lowered, &map);
-        assert_eq!(restored, input);
-    }
-
-    #[test]
-    fn leaves_value_bindings_untouched_when_already_correct() {
-        let input = r#"<card tinted="@[selectedEquipProps(uuid).element]"></card>"#;
-        let map = capture(input);
-        // Value bindings keep case through html5ever, so output already matches.
-        let restored = restore(input, &map);
-        assert_eq!(restored, input);
-    }
-
-    #[test]
-    fn noop_when_no_uppercase() {
-        let input = "<icon @[tooltip.props.element]></icon>";
-        let map = capture(input);
-        assert!(map.is_empty());
-        assert_eq!(restore(input, &map), input);
-    }
-}