3.2.0 - You're an All-Star

What's Changed

The hits keep coming and they don't stop coming.  Hot on the heels of the 3.1.0 release, the 3.2.0 release has landed, with a another round of substantive improvements.

Email Templating Overhaul

The email templating system has been completely overhauled. What was previously the Email Template module has now been broken into two sub modules:

• Inky Module - This module now hosts the JSX components (no more html files) used for generating the Inky email content.  This module has zero dependencies on the compilation process, and so can safely be included as a non-dev dependency without fear of affecting the final output size. 
  
  The biggest change here is that templates are now compilable (and checkable) for errors, etc.  This was the last major piece of the framework that wasn't based in Typescript, and now that has gone away.
  
  
• Compiler Module - The compilation process is now completely decoupled from the underlying templating framework.  This allows for all the compilation dependencies to be safely isolated as dev dependencies, but also has the added benefit of cleanly allowing future email templating frameworks to be used as well.
  
  In addition to the structural change all the CLI tooling has been updated for emails, including the abillity to trigger email sending from the command line for testing purposes.  Previously all the commands relied on the resource key of the email template, which was confusing to say the least.  Now that all emails are source code, the file path is all that is needed for execution.

Rest Client Support (separate from Openapi Generator)

Until recently, the only way to generate client code was using a custom Openapi code generator and leveraging the openapi.yaml generation provided by the Openapi module.  While useful, and providing a huge array of output formats, left a lot to be desired in the performance arena.  This release sees the introduction of a new module, Rest Client, that enables fast, clean, and simplified client generations specifically for Typescript ecosystems. 

• Tighter Integration with Code Change Detection - The main goal here is to piggyback on the class/file change detection that already exists, and leverage it to produce a minimal client.  
• Better Usage of Native Typescript Primitives -  This provides the ability to have full control over the output versus depending on whatever design decisions the Openapi Generator codebase has.  This means tighter integation on Typescript features, and less bulky generation processes.  
• Optimized Output - The output now produces far fewer files, adds zero additional file watches, and responds much faster to changes in the rest/model schemas.
• Multiple Outputs with a Single Project - Additionally, the code generation runs in process with the containing code, and is able to produce multiple outputs with a single process.  This opens the door for generating node-based clients, as well as web-based clients simultaneously.
• Initial Supported Formats -
• Fetch + Node - A node-based fetch-backed implementation
• Fetch + Web - A web-based fetch-backed implementation
• Angular 15+ - An angular-backed implementation

Native Fetch

Throughout the framework, there has been a perpetual need for making HTTP requests, but generally in the realm of testing and verification.  With the advent of the new RestClient module, there is now a tighter integration with crafting and invoking HTTP requests.  As of Node v18, the Fetch client is baked into the runtime, and is globally accessible (providing parity with Web-based environments).  While still an experimental feature, it is well on its way to achieving stability.  To that end, all references to node-fetch have been removed throughout the framework, and the framework's minimum node version is now bumpted to v18.  

Model + Query Enhancements:

• Inheritance Standardization - Previously Model  and Schema approached the concept of base classes and differentiation slightly differently, even though Model depended on Schema.  This latest round of changes has standardized these patterns providing consistent understanding of how that is modeled within the framework.
• Atomic Update Support - Within the Model query module, there is now an atomic update operation, that relies on a query to match before the update is applied.  This is very useful for optimistic locking based on a field value (e.g. a version key).   
• Existance Checks and Empty Arrays - The Model query module now supports the ability to filter elements based on whether or not an array is empty or not.  Some model providers do not store empty arrays where others do.  This helps to standardize the behavior, treating empty arrays as not existing.
• General Fixups - File, Memory and S3 all received various bug fixes related to stability and standardization of behavior.

Auth Cleanup

• Auth JWT Session-Like Support - The Auth JWT module now allows for auto regenerating a new token depending on how close the token is to expiration.  When combined with the cookie encoder, this provides a mode in which the user will continue to renew the token, providing a semblance of the session timeout/renewal.
• Removal of Auth Rest Context - This functionality is now basked into Auth-Rest

Miscellaneous Enhancements

• Upgraded all dependencies to latest versions
• Custom Rollup Support - Allow for complete control of the rollup behavior, providing similar functionality to that of specifying/controlling the entire docker file.
• Standardization of all Query-based complex types (e.g. schema-backed objects mapped to query params) - We now have consistency between OpenAPI, Rest, and Rest-Client on how these types will be handled, and how prefixing of values will apply.