What's Changed
This is major release that internally has reworked the "Dynamic" portion of the framework, along with a refactor of the "Registry" structure. Nearly all of this is internal, and usually non-user facing, but there are some caveats.
Re-imagining Dynamic
Since the beginnging of the framework, the goal has always been towards being dynamic. This included concepts like hot module reloading, route registration, and updating database schemas on demand. This has generally been working for nearly a decade, but there were a lot of edge cases that wouldn't work just right. These stemmed around things like base classes, shared external types (type unions), etc. Essentially indirection and complex structures, especially externalized, left us open for gaps.
With this release, hot module reloading is gone (along with heaps of supporting code). The framework now supports running in a mode that will automatically restart the application on the appropriate file changes. This has verifiably worked well with debuggers, and should provide a nearly identical experiance as compared to before.
Additionally, when in development, theh framework will reconcile the database schema on startup. This means inspecting the existing database structure, and comparing to what we would have created if writing from scratch, and adjusting the difference. This covers a litany of edge cases, the least not being switching branches, or making any other changes when the app isn't running.
Registry Unification
As we march closer to Typescript 7 (now with more Go), one of the biggest points of conflict will be the transformer logic the framework employs. Before this release we had about 5 major transformer: cli, di, schema, model, test and web. Each of these modules' transformer was doing nearly the same thing. Check for decorators, add metadata, verify types.
With this release, all that remains are schema and test. For schema, all the logic/metadata those other modules were collecting are either subsumed into the schema structure, or stored explicitly via the decorator and not the transformer.
This greatly reduces the surface needed to handle when looking towards Typescript 7.0. The goal will most likely be to port the typescript to Go and provide a native version of the transformers that can operate within a custom compiled version.
ES Module Migration
With the removal of the dyanmic module reloading, the last remaining piece keeping the framework supporting CommonJS has been removed. This allows the framework to completely drop all "dual" support for CommonJS/ESM, and focus solely on ESM. The codebase already supported ESM, but this will allow for a more streamlined experience, as well as reduced burden for testing/verification. Given ESM is the future, this is a natural optimization given the other changes in this release.
General Improvements
General house keeping (depenency bumps), down stream alignments (e.g. VS Code plugin), code hygenie are all on the list of general improvements.
Whats Next?
The ecosystem is still waiting (5+ years now) on ES Decorators being fully ratified (including parameter decorators), including support for standalone functions. Once all the necessary features are available within Typescript, the framework will overhaul decorator behavior, and allow for isolated functions where it make sense (e.g. DI factory functions, standlone web routes, caching, etc).
Also, with the notice that Typescript will be moving to Go for version 7+, we will continue to keep an eye on what the story is for custom code transformers. There is a high chance the transformation logic, that is currently in Typescript will need to be ported to Go.
No comments:
Post a Comment