Integrate Inja Code Generation - #5
Open
cerupcat wants to merge 29 commits into
Open
Conversation
* add-data-binding: refactor: prefer camelCase chore: fix build warnings feat: add windows build scripts chore: bump rive runtime submodule chore: clang formatting feat: add data binding
added 5 commits
November 7, 2025 13:15
…nV3.riv. The root cause was missing null pointer checks in three places: 1. Nested ViewModel Property Access (main.cpp:691-693) Problem: Chained calls viewModel->createInstance()->propertyViewModel() without null checks Fix: Added null checks for createInstance(), propertyViewModel(), instance(), and viewModel() 2. Enum Property Access (main.cpp:730-736) Problem: Chained calls accessing enum properties without null checks Fix: Added null checks for createViewModelInstance(), propertyValue(), and all subsequent property accesses 3. Default Value Property Access (main.cpp:786-818) Problem: Accessing property values without null checks for boolean, number, string, and color types Fix: Added null checks for each property value access 4. Nested Artboard Instance Access (main.cpp:525) Problem: nested->artboardInstance() could return null causing crash during recursion Fix: Added null check before recursively calling getNestedTextValueRunPathsFromArtboard() 5. Default Artboard Instance Access (main.cpp:882) Problem: defaultArtboard->instance()->defaultStateMachine() without null check on instance() Fix: Added null check for instance() before accessing defaultStateMachine()
Resolved conflicts: - build/build.sh: Kept template paths with mustache/ subdirectory structure - src/main.cpp: Kept Inja integration and metadata features - Removed duplicate templates/viewmodel_template.mustache (we have templates/mustache/viewmodel_template.mustache)
cerupcat
marked this pull request as ready for review
January 6, 2026 00:47
Adds a --lint mode to the code generator that validates .riv files against asset format and size rules, and checks that every artboard has at least one state machine. New CLI flags: --lint Enable lint validation; exits non-zero on violations --allowed-extensions Comma-separated list of allowed image formats (default: webp) --max-asset-size Max embedded asset size in bytes (default: 204800 = 200 KB) --lint-format Output format: text (default) or json -o/--output is now optional; omitting it with --lint runs lint-only with no code generation. Implementation details: - LintingFactory subclasses NoOpFactory and overrides decodeImage() to capture embedded image byte sizes during File::import() - Embedded vs CDN-hosted assets are distinguished via cdnUuidStr(); only embedded images have a corresponding factory entry - embeddedByteSize added to AssetInfo and populated via factory size correlation in getAssetsFromFile() - openFile() now accepts a Factory& instead of using a static NoOpFactory, enabling per-call factory instances - runLint() checks format (fileExtension()), size (embeddedByteSize), and state machine presence against LintConfig - outputLintViolations() supports both text (stderr) and json (stdout) output Assisted by AI Co-Authored-By: Claude <noreply@anthropic.com>
…d add --lint flag Extracts the 1800-line main.cpp into: - types.h: all shared enums and structs (RiveFileData, LintConfig, LintViolation, etc.) - string_utils.h: inline case-conversion and sanitization helpers - rive_file_parser.h/cpp: file discovery, Rive runtime parsing, asset/artboard extraction - lint.h/cpp: LintingFactory, runLint(), outputLintViolations() - template_renderer.h/cpp: loadTemplate(), renderTemplate(), Mustache/Inja data builders - main.cpp: lean CLI setup and top-level flow Adds --lint flag with configurable --allowed-extensions, --max-asset-size, and --lint-format (text/json). Can run lint-only (no -o) or lint + codegen combined. Assisted by AI Co-Authored-By: Claude <noreply@anthropic.com>
…t.inja template Adds fields that the template expects but were never populated: - file.has_view_model - artboard.is_default / artboard.has_view_model - vm.is_first - prop.last Assisted by AI Co-Authored-By: Claude <noreply@anthropic.com>
asset->fileExtension() returns the source filename extension set at import time (e.g. "png"), not the actual embedded format. Re-encoding to webp in the Rive editor changes the bytes but not the metadata, causing false positive lint errors. LintingFactory now sniffs the first 12 bytes of each embedded image in decodeImage() and stores the detected format alongside the byte size. getAssetsFromFile uses the detected extension for embedded images, falling back to asset->fileExtension() only for unrecognized formats. Matches rive-runtime's own Bitmap::RecognizeImageFormat() approach. Assisted by AI Co-Authored-By: Claude <noreply@anthropic.com>
…nced assets The previous approach correlated decodeImage calls with file->assets() by index, which breaks when referenced assets (no in-band bytes) are interspersed with embedded ones — the index shifts and the wrong asset gets the embedded info. Replace LintingFactory (decodeImage override) with LintingAssetLoader (FileAssetLoader): - loadContents receives (asset, inBandBytes, factory) for every asset - inBandBytes.size() > 0 → embedded; captures size + magic-byte format by asset name - inBandBytes.size() == 0 → referenced or CDN; skipped - Returns false so normal decode proceeds via NoOpFactory getAssetsFromFile now looks up asset info by name (unordered_map) instead of index, which is correct regardless of asset ordering in the file. lint.cpp already guards format/size checks with embeddedByteSize > 0; referenced and CDN assets now correctly have embeddedByteSize == 0 in all cases. Assisted by AI Co-Authored-By: Claude <noreply@anthropic.com>
…n map insert Assisted by AI Co-Authored-By: Claude <noreply@anthropic.com>
…nary update) Assisted by AI Co-Authored-By: Claude <noreply@anthropic.com>
Co-authored-by: Codex <codex@openai.com>
Codegen disambiguates duplicate asset names for identifier generation (a second "SF-Pro" becomes "SF-ProU1"), but runtimes resolve referenced assets by the file's real "<name>-<assetId>" key (the exported uniqueFilename). Templates that bake asset keys into generated code — like rive-assets' fontAssetIds/fontAssetNames — had only the uniquified name available, so generated font keys never matched what the runtime looks up and text bound to those fonts rendered without glyphs. asset_name and the case variants stay uniquified for identifiers; asset_raw_name carries the name exactly as authored in the .riv, in both the inja and mustache renderers. Assisted by AI Co-Authored-By: Claude <noreply@anthropic.com>
Expose raw (non-uniquified) asset names to templates as asset_raw_name
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Integrate Inja Template Engine
Overview
This PR adds support for the Inja template engine as an alternative to Mustache, providing more powerful templating capabilities for code generation while maintaining full backward compatibility with existing Mustache templates.
Motivation
Mustache templating is limited in terms of logic and requires the data source to provide granular details (e.g., array size counts, whether a property exists, last element detection). Inja is a modern C++ templating language that provides more control flow and expressions without requiring the data source to be overly detailed.
Key Features
1. Dual Template Engine Support
-e, --engineflag to choose betweenmustache(default) andinja{% if condition %}{% for item in items %}withloop.is_first,loop.is_lastlength(),upper(),lower(), etc.{% include "partial.inja" %}2. Enhanced Metadata & Relationships
3. Private Element Filtering
--ignore-privateflag to exclude elements based on naming conventions:_(underscore)internal(case-insensitive)private(case-insensitive)4. Modular Swift Templates
{% include %}feature5. Template Organization
templates/mustache/- Mustache templatestemplates/inja/- Inja templatestemplates/custom/Swift/- Modular Swift template exampleChanges Summary
37 files changed, 32,265 insertions(+), 63 deletions(-)
Core Changes
TemplateEngineenum and rendering logicshouldIncludeElement()for private filteringTemplate Infrastructure
Templates & Examples
Testing & Documentation
Usage Examples
Basic Inja Template Usage
# Generate code using Inja template ./rive_code_generator -i samples/rating.riv -o output.swift \ -t templates/custom/Swift/swift_example.inja -e injaWith Private Filtering
# Exclude private elements ./rive_code_generator -i samples/ -o output.dart \ -t templates/inja/dart_template.inja -e inja --ignore-privateModular Templates with Includes
The Swift templates demonstrate using includes for modular organization:
Testing
All 7 tests pass:
Backward Compatibility
Additional Improvements
Note: This implementation maintains full compatibility with upstream while adding powerful new templating capabilities that don't require data source modifications.