Another minor release of UserFrosting is out, and includes some more behind-the-scenes improvements to the assets pipeline. This was originally set for release in 4.3 but was pushed back when I deleted a folder at a higher level than was intended, a harsh lesson on the importance of backing up (and committing) often.
As with my last UF update announcement, I'll be providing an overview on the changes I was involved in implementing.
🔧 Assets Pipeline
My focus for this iteration of the assets pipeline was to address 3 of the weaknesses remaining from the 4.2 overhaul;
- Overridden files are unnecessarily read, increasing amount of IO.
- All assets are loaded into memory before processing commences, at the expense of RAM.
- Significant backpressuring in the stream, which delays later processing.
Key to addressing these problems was the creation of
@userfrosting/vinyl-fs-vpath, a Vinyl file system source that resolves a virtual path mapping to determine which files should be loaded into memory. Extracting and optimising this logic that previously resided in
@userfrosting/gulp-bundle-assets drastically increased maintainability by improving separation of concerns, particularly as it is now able to start processing bundles as soon as its dependencies are met (as opposed to once every stream file has been received).
By far the hardest part of creating
@userfrosting/vinyl-fs-vpath was working with file paths, a deceptively complex topic when it is important to maintain compatibility with the quality of life decisions in Gulp JS. Rather than manually re-implement all of them (which would be a nightmare to test),
vinyl-fs was utilised internally for loading each file which pushed progress forward significantly.
@userfrosting/gulp-bundle-assets package had a relatively extensive refactoring (diff) performed resulting in;
- Improvements to logging, with a standard logging interface (
ts-log) being adopted. Timing of logging has also been drastically improved.
- Fixing results callback interface (the bug in v3 resulted in UserFrosting having to implement a workaround).
Using well tested and maintained packages over previous internal solutions, including;
- Enabling strict checks in the TypeScript configuration, and fixing numerous small corner cases (and removing redundant guards).
- Adding API docs generated from TypeScript types and code comments.
- Drastic increase to test coverage to 100% (with few branch ignore rules that are slowly being eliminated where possible).
While most of the potential improvements have been realised, some more still remain including;
- Allowing custom sub-stream types (instead of just scripts and styles) to permit more advanced scenarios. This would also simplify the code.
- Removing need for the
esmpackage in version of Node natively supporting ES modules.
🔭 Looking Ahead
Since UserFrosting 4 came out, the ecosystem around web development has changed radically. ES modules arrived and is fast becoming the standard standard module format with Node JS and browsers adding native support. With the rise of frameworks like
Angular (not to be confused with
AngularJS), libraries like JQuery have fallen out of favour. Web development tooling has innovated at an exceptionally rapid rate, encouraging decoupling of the GUI such that the backend API (if needed at all) doesn't become a bottleneck. Alongside this smart phones have made themselves a part of our everyday lives, meaning there is often strong motivation to create a app for websites.
My goal for UserFrosting 5 is to support this new development methodology without requiring implementors to perform a complete rewrite. Central to this will be a shift to using skeleton projects (over the current "everything in the repo" approach currently used) which will offer the needed flexibility. My own prototyping will be occurring at https://github.com/Silic0nS0ldier/uf5-prototype, feedback via the UserFrosting Chat or Twitter is welcomed.