v1.3.0 Liminal: Beyond the Threshold
Empowering dynamic environments with flexible I/O traits for alternative storage solutions, moving beyond filesystem constraints. Enhanced error logging ensures smooth development flow, gracefully handling incomplete or incorrect Spells in watch modes.
We aim to make Grimoire CSS more flexible by allowing two distinct usage modes:
-
File-based mode (exist…
Empowering dynamic environments with flexible I/O traits for alternative storage solutions, moving beyond filesystem constraints. Enhanced error logging ensures smooth development flow, gracefully handling incomplete or incorrect Spells in watch modes.
We aim to make Grimoire CSS more flexible by allowing two distinct usage modes:
-
File-based mode (existing
Config
structure)- Reads input paths from the filesystem; writes compiled CSS to files.
-
In-memory mode (a new
ConfigInMemory
structure)- Accepts raw CSS data or user-defined strings directly in memory; returns compiled CSS as data structures instead of forcing file output.
This enhancement means Grimoire can be easily integrated into serverless environments or web frameworks where storing both configuration and final CSS in a database (or a remote store) is preferred.
Key Milestones / High-Level Steps
-
Define a New
ConfigInMemory
. -
Add Dedicated Functions/Methods for In-Memory Building (these methods parse or transform in-memory data and produce a compiled CSS result without reading/writing the disk).
-
Adapt Internal Parsing/Compilation.
-
Retain File-Based Logic (ensure the existing file-based flow remains untouched).
-
Document and Test.
Why This Approach Is Preferable over a Trait-Based IO Layer
-
Simplicity
- A trait-based IO approach might demand rewriting many methods to support arbitrary streaming or readers/writers. Given that CSS parser expects a full string, streaming offers little advantage.
- Maintaining a large trait with many streaming or iterator-based methods could be overkill if most real-world scenarios only need “read full content / produce full content.”
-
Clear Separation
- By having
Config
for the file-based approach andConfigInMemory
for the in-memory approach, it’s immediately obvious which mode you’re using. There’s no confusion with half-populated fields or conditional checks.
- By having
-
No Changes in the Existing Flow
- We don’t break existing file-based workflows or rename existing APIs. Current users can keep doing what they do, unaffected.
- We add a brand-new, simpler path for those who want direct memory usage.
-
Practical Coverage
- Nearly all feature requests revolve around “I want to store data in a DB or memory, then feed it to Grimoire, and get the result as a string.” That’s exactly solved by an in-memory config model, without the overhead of building a generic trait-based streaming system.
Hence, this approach balances ease of implementation, and comprehensive coverage for typical scenarios - especially given the nature of CSS-parsers working on complete CSS strings.