Polymerize v0.8.1 is out

Polymerize v0.8.1 is Out

A new version of polymerize is out with many new features and changes under the cover.

More dart code less js

Previously polymerize was generating a lot of JS code and html glue in order to fix the gaps between the @JS interop layer and what is needed to make dart DDC generated code work with polymer version 2.x (like registration of elements and replacing the standard html lib with package:html5).

From this version the most code is generated in dart land and translated to JS by DDC. Only a few native JS library are kept and used from dart by means of the @JS interoperability layer.

This approach makes the code more easy to understand and to maintain and it ready to be used in the upcoming pub+ddc.

Introducing package:polymerize_common

A new package enters in the polymerize family; it is package:polymerize_common.

This package defines a few basic annotation that are common to any polymerize project:

Better module strategy

In the previous version a single js file was generated for a whole package. Now a js module is generated for every .dart file in your project or dependency.

This allow for a better control on what has to be dynamically loaded at runtime. Thus now using a singole component say in polymerize_elements will not force you to load the whole polymer_elements compoents but only those you are actually using.

Use of the real DDC

Now the current dartdevc compiler that comes with the SDK is used instead of a library extracted from the git repository like in the previous versions. This allows for a simpler and more transparent matching with the current SDK.

Workers for bazel !

Now polymerize uses the bazel workers protocol in order to speed up compilation. Some work needs to be done to improve because at the moment a lot of memory is consumed by each workers forcing to kill them when they get to big (bazel shutdown).

bower in the workspace

In the previous version bower was run as a BUILD rule in the main BUILD file. As Bazel doesn’t like rules that produces an unknown number of outputs this was actually a dirty hack.

Now bower will define an external workspace and a BUILD file will be created enumerating every asset that has to be part of the build.

This in turns need that if you want to force bazel to recreate the @bower external workspace from stratch you have to force a hard cleanup of bazel (with bazel clean --expunge).