List view
Grimoire CSS v1.5.0 Arcane Nexus unifies the ecosystem with powerful new commands, modular external scrolls and variables, advanced template syntax, and a public color toolkit.
No due dateGrimoire CSS enhances its magical arsenal with the **v1.4.0 Aetheric Flow** release, bringing refined argument handling, enhanced visual feedback through new spinners, and improved CLI flow. This update focuses on the quality-of-life improvements that make spell-casting (development) more intuitive and visually engaging.
No due date•6/6 issues closedEmpowering 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**: 1. **File-based mode** (existing `Config` structure) - Reads input paths from the filesystem; writes compiled CSS to files. 2. **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** 1. **Define a New `ConfigInMemory`**. 2. **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). 3. **Adapt Internal Parsing/Compilation**. 4. **Retain File-Based Logic** (ensure the existing file-based flow remains untouched). 5. **Document and Test**. --- ### **Why This Approach Is Preferable over a Trait-Based IO Layer** 1. **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.” 2. **Clear Separation** - By having `Config` for the file-based approach and `ConfigInMemory` 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. 3. **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. 4. **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.
No due date•7/7 issues closedExpanding styling possibilities with fluid sizes, built-in color functions, and refined, dynamic adjustments.
Due by December 22, 2024•8/8 issues closedIntroducing foundational tools and optimizations, including new plugins and enhanced performance.
Due by November 22, 2024•11/11 issues closed