PRNext 0.1.15: stronger runtime foundations
PRNext 0.1.15-alpha updated several layers beneath the application: TLS validation, image dependencies and the supported Node.js baseline.
Those changes are also included in 0.1.16-alpha. If you are updating now, use 0.1.16 with the aligned React 19.3.1 packages rather than stopping at this earlier release.
TLS and certificate validation
The release updated rustls, rustls-webpki and webpki-root-certs, including a fix for a distrusted emSign intermediate certificate.
This work concerns the native runtime’s dependency chain. Your own application dependencies and external services still have their own update requirements.
Certificate validation belongs to the connection path, so a patched native dependency matters even when application source does not change. Test the external HTTPS services your application relies on after rebuilding. A successful request to one service does not establish that every certificate chain or application-specific client is covered.
Image and Open Graph rendering
The dependency lock moved to sharp 0.35.5 and source-map-js 1.2.2. The shipped Open Graph renderer was rebuilt, with a resvg fallback when an optional native sharp backend has a missing or older-than-2.63.2 librsvg.
Checking only a workspace override is not enough for code already embedded in a distributed renderer. The packaged output must include the corrected dependency too.
The fallback concerns how the packaged renderer handles its native image backend. Verify both an ordinary optimized image and a generated Open Graph image in the built application. Those paths can exercise different code, so a correct thumbnail alone is not a complete check of social-image generation.
A patched Node.js baseline
Supported release lines start at Node.js 22.23.4, 24.22.1 and 26.12.1. The local Node executable and deployed container images need their own update; installing an npm package does not replace them.
Treat the Node runtime and application artifact as two parts of the deployment. Record which executable or container image starts the application, rebuild with the intended package versions and check the running service after restart. This avoids keeping a patched lockfile beside a process that still uses an older runtime.
Where to go from here
Use the 0.1.16 instructions for the package documented in the installation guide, rebuild your application and restart the deployed output. The development and cache changes in 0.1.17 are covered in their own versioned articles.
Keep a record of the artifact and runtime that passed those checks. If you need to roll back application code, that record helps distinguish a functional rollback from reintroducing an outdated dependency. Validate the replacement output instead of assuming an older image has the same security properties.