3.4.0 - Under the Hood

What's Changed

This release is aimed at bringing quality of life improvements to general tooling, with a strong emphasis on compiler orchestration.

Compiler Overhaul

The compiler orchestration has been completely rewritten.  The logic for managing concurrent build requests, watching files, communicating with running servers, etc. has been centralized into a compiler server.  This server owns the lifecycle for compliation, restarting on workspace invalidations, and the like.  The logic that was previously shared between the compiler and the VS Code extension now lives solely within the compiler.  

This overhaul also precipated an audit of all file-based operations, ensuring atomicity of write behavior and also that concurrent requests would not interfere (e.g. a request to clean occurring in the middle of a build cycle).

File Watching 

Previously, the manifest module provided primitives for file watching, and the base module would build upon that for simple use cases.  The main need for watching within the framework, was to watch for changed source files. These file watches were extremely problematic across multiple operating systems, and ensuring everything worked correctly was a challenge.  Even with the introduction of @parcel/watcher, challenges still arose. 

To ensure the primary use case was honored, the compiler server now provides a stream of change events that fire after the file is guaranteed to be compiled, and the manifest has been updated.  This means that filesystem watching is no longer a concern for the framework, but listening to compiler changes is.  The main benefit here is that the watch logic can be replaced/changed/etc, and it only affects the compiler.

As a note, there is still need a for watching files in the email-compiler module, and so a simple integration with parcel's watcher makes quick work of it.  

Config

To the outside, there is nothing that has changed here.  The biggest difference is now a clearer contract for prioritization of various config sources, as well as the ability to support multiple files. This has a direct benefit for the mono-repo setup. but provides a clear contract of what happens when the same file shows up in multiple folders.  This follows the resource provider pattern of, mono-repo >> module >> resource paths.  

General Simplifications

As with every release, one of the underlying goals is to align the codebase with standards within the NodeJS ecosystem, as well as incoporating changes to the built-in APIs (e.g. the switch to fetch).  This release sees more and more internal code removed in favor of standards or simpler solutions.  The net result is a smaller, simpler code base that follows closer and closer with best practices.  

The beauty of this process is that the public API shape is unchanged, which allows for such an invasive change to register as a minor release.  

Whats Next?

The ecosystem is still waiting 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 rest routes, caching, etc).