Bump minimum Dart SDK to 3.3 (to support extension types)
Adds JsonValue hierarchy for representing JSON primitives safely
Model/exception types from third-party packages no longer need to be exported from models.dart/exceptions.dart. Only types you've defined.
Adds support for lib/models/ and lib/exceptions/ folders for better organization of custom types
This release also adds a new way to control serialization called "custom overrides".
There are times when you want to use a type from a third-party package in an API, but it is not serializable and Celest complains when you do so. Because you do not control the package, you cannot make it serializable and you are stuck. Other times, the opinionated way Celest serializes (e.g. by using fromJson/toJson methods if available) doesn't align with how you've defined these APIs.
In both of these situations, custom overrides allow you to reimagine the types so that they can be serialized with Celest.
Consider a type called MyType which has fromJson/toJson methods you cannot control and which are causing errors with Celest. The simplest override of this type would look like this (defined in lib/models/overrides.dart):
import 'package:some_package/some_package.dart';
@override
extension type MyTypeOverride(MyType _) implements MyType {}
The @override annotation tells Celest to use this type instead of the original MyType when it encounters a MyType value at any point. The override applies globally and affects all instances of MyType when passing from client<->server. And since MyTypeOverride does not define fromJson/toJson methods, Celest will generate its own.
Custom overrides can do a lot more than override fromJson/toJson methods, though. They can redefine constructors, fields, and even field types. And custom overrides work for exception types too (define those in lib/exceptions/overrides.dart)!
Fixes
35
38
43
48
49
Deprecations
DEPRECATEDlib/models.dart/lib/exceptions.dart have been deprecated in favor of lib/models/ and lib/exceptions/ folders
Breaking Changes
BREAKING Fixes casing of resource types (e.g. @env.myEnvVar -> @Env.myEnvVar)
dnys1
commented
7 months ago 
JsonValuehierarchy for representing JSON primitives safelymodels.dart/exceptions.dart. Only types you've defined.lib/models/andlib/exceptions/folders for better organization of custom typesThis release also adds a new way to control serialization called "custom overrides".
There are times when you want to use a type from a third-party package in an API, but it is not serializable and Celest complains when you do so. Because you do not control the package, you cannot make it serializable and you are stuck. Other times, the opinionated way Celest serializes (e.g. by using
fromJson/toJsonmethods if available) doesn't align with how you've defined these APIs.In both of these situations, custom overrides allow you to reimagine the types so that they can be serialized with Celest.
Consider a type called
MyTypewhich hasfromJson/toJsonmethods you cannot control and which are causing errors with Celest. The simplest override of this type would look like this (defined inlib/models/overrides.dart):The
@overrideannotation tells Celest to use this type instead of the originalMyTypewhen it encounters aMyTypevalue at any point. The override applies globally and affects all instances ofMyTypewhen passing from client<->server. And sinceMyTypeOverridedoes not definefromJson/toJsonmethods, Celest will generate its own.Custom overrides can do a lot more than override
fromJson/toJsonmethods, though. They can redefine constructors, fields, and even field types. And custom overrides work for exception types too (define those inlib/exceptions/overrides.dart)!Fixes
35
38
43
48
49
Deprecations
lib/models.dart/lib/exceptions.darthave been deprecated in favor oflib/models/andlib/exceptions/foldersBreaking Changes
@env.myEnvVar->@Env.myEnvVar)