[ANN] sc.recipe.staticresources 1.0a1

Plone Support Add-on Development
, ,
1

Continuing the discussion from List of tested and production-ready plone.app.mosaic tiles for Plone 5.1?:

sc.recipe.staticresources 1.0a1 was just released including some of the ideas @rodfersou has worked over the last months on how to deal with static resources using modern technologies in Plone 4.3 (and maybe Plone 5) on a sane, non-disruptive way.

sc.recipe.staticresources is a buildout recipe to integrate Webpack into Plone.

In recent years many tools were created to manage static resource files; these tools can:

* automatically compress images
* use CSS pre-processors and post-processors to write less and better code, taking advantage of new standards still not available to all browsers
* use JavaScript transpiler to write ES6 code and generate ES5 equivalent code, that work on all browsers
* minify resulting code
* and many other options, practically everything related to process static resources can be achieved by an official or community package

This package is aim to facilitates the integration of Webpack with Plone, writing less lines into your buildout configuration and provide a nice template to start with.

We choose Webpack because it is proven to be the best toolchain available, and many people in the Plone Community is using it.

the resulting optimized static files are registered into Plone 4.3 the usual way.

if you want to take a look on how this work on real life, see this PR:

1 Like
2

just a quick update on this: we are using it in the new version of a package that contains 4 or 5 different themes for Brazilian government sites:

this is work in progress and we are learning every day.

2 Likes
3

we recently released version 1.0a2; a couple of related pull requests as an example of how this recipe can be used to simplify your life compared with current approaches (just look at the change statistics):

refactoring static resources without the recipe:

refactoring static resources with the recipe:

1 Like
4

The comparison is a bit unfair as PR 51 is adding the lazysizes repository via npm, which makes most of the changed files. The advantage here is that anyone can use any other of the provided lazysizes plugins just by registering the resource in registry.xml. PR 53 doesn't add the lazysizes repo. However, using webpack for building the bundle is an advantage of PR 53.