Webiny 5.10.0 Changelog

See what's new in Webiny version 5.10.0.

Changes

This document highlights the most important fixes, improvements, and features, that were introduced in Webiny 5.10.0.

How To Upgrade?

Please check the Webiny 5.10.0 migration guide for the upgrade steps.

Infrastructure

Node 12 Runtime and a New Sharp Layer (#1738 )

With AWS deprecating Node 10 Lambda runtime, we’ve also upgraded all of our Lambda functions to use Node 12 (you may have noticed that File Manager Lambdas were using node 10). With that, we also released a new version of Sharp layer, which is twice smaller, and also supports Node 14, so we have the peace of mind for the near future.

The upgrade process will take care of the existing projects and will link your existing Lambdas with the new Sharp layer, and switch to Node 12.

Page Builder

Website Fixes (#1746 , #1752 , #1755 )

We discovered a couple of issues that would sometimes occur while the user is navigating through the public website.

First of all, a really easy-to-miss Apollo cache-related issue would sometimes cause the pages to stop being shown correctly, forcing the user to refresh the page. We believe the changes we made in #1746 external link will fully address this.

We should also mention that we’ve managed to revisit the existing Pages List page element and that all of the community-reported issues were resolved. For more information, please check linked pull requests.

Preloading and Caching Improvements (#1753 )

The following improvements should improve the page load times for pages created with Webiny Page Builder external link .

Asset Preloading

Once a page has been published, in the static page generation process that follows, all links to JS and CSS files will now utilize the rel="preload" attribute :

The preload value of the <link> element’s rel attribute lets you declare fetch requests in the HTML’s <head>, specifying resources that your page will need very soon, which you want to start loading early in the page lifecycle, before browsers’ main rendering machinery kicks in. This ensures they are available earlier and are less likely to block the page’s render, improving performance.

Except redeploying your project, no special steps are needed in order to receive this improvement.

To double-check whether this new improvement is working as expected, open the source code of any published page in your browser. In the <head> section, you should be able to see the new rel="preload" attributes, for example:

<!DOCTYPE html><html lang="en"><head>   <link as="style" rel="preload" href="/static/css/2.1edd21d9.chunk.css" />   <link as="style" rel="preload" href="/static/css/main.30bba61e.chunk.css" />   <link as="script" rel="preload" href="/static/js/2.229acfe0.chunk.js" />   <link as="script" rel="preload" href="/static/js/main.680e9d72.chunk.js" />  <meta charset="utf-8" />  (...)

Added Missing `Cache-Control` Response Headers

Upon visiting any published page, all of the static JS, CSS, and images that are part of the Website React application’s production build, will now be served with proper Cache-Control headers. Ultimately, once downloaded, these files will now be kept in browser’s cache, making subsequent website renders noticeably faster.

Development

Admin Area React Application - Reduced Deployment Time (#1740 )

Prior to this release, every time we’d deploy the Admin Area project application (apps/admin ), all of the React application’s production build files (JS, CSS, images) would be re-uploaded from scratch, even if we didn’t perform any changes in our application code.

From now on, files whose content didn’t change simply won’t be uploaded. This will significantly speed up the deployment of the Admin Area project application.

Project Applications

Learn more about project applications and project organization in general, in the Project Applications and Packages key topic.

Improved Existing Scaffolds (#1739 )

A couple of minor fixes and improvements were made to the scaffolding utilities, introduced in the previous Webiny 5.9.0 release.For example, if you already had the chance to use the Extend GraphQL API scaffold, you might notice that the default location in which the application code is generated has been changed:

# Previously, all of the application code would be generated within the following path:
api/code/graphql/src/plugins/scaffolds/graphql/carManufacturers

# This is the new path, without the "graphql" folder:
api/code/graphql/src/plugins/scaffolds/carManufacturers

The same change was applied to the Extend Admin Area scaffold, where the redundant admin folder was removed:

# Previously, all of the application code would be generated within the following path:
apps/admin/code/src/plugins/scaffolds/admin/carManufacturers

# This is the new path, without the "graphql" folder:
apps/admin/code/src/plugins/scaffolds/carManufacturers

For other related changes, please see the linked pull request.