Address issue with r2 choking on Clay/Bootstrap 4

[robframpton]

When building a theme that implements Clay 2.0, the r2 task seems to choke on something in either Clay or Bootstrap 4.

We need to investigate if this is an issue in one of those libraries or in our fork r2 itself (https://www.npmjs.com/package/liferay-r2).

[robframpton]

On another note, we should probably move https://github.com/jbalsas/R2 to the liferay org, as it's still used by the theme tools. Unless there is a way for the themes in 7.1 to leverage the java based tool in Portal, maybe a servlet filter?

@jbalsas

[jbalsas]

We probably can't, we don't have sass compilation in portal anymore, everything gets done at build time. We would need to tap into the java tools if we wanted to leverage it.

We could do something similar to what we have in metal-tools-soy to leverage frontend-css-rtl-converter via a released artifact

Needless to say this would add a jvm dependency on the project ❤️

[robframpton]

Well technically the r2 stuff runs post sass compilation. We're just running it on .css files in the theme tasks.

[jbalsas]

You're totally right! Nevertheless, we don't run it on the server anymore :)

[jbalsas]

Hey @Robert-Frampton, @pat270, @marcoscv-work, I think this is happening because we have some kind of issue in clay. Based on the css output, from list-group

[...]
    .list-group {
        @if ($list-group-box-shadow != null) {
            @include box-shadow(none);
        }
    }
[...]

Seems to be producing:

[...]
.list-group {
  border-radius: 0.25rem;
  -webkit-box-shadow:;
  box-shadow:;
  color: #6B6C7E; }
[...]

This is likely causing the rtl process to fail to parse it. Makes sense? Can we get rid of that mixin or make sure it produces valid css?

[jbalsas]

Hey @Robert-Frampton, @pat270, wasn't this already addressed in clay?

[pat270]

Yes was fixed at https://github.com/liferay/clay/commit/774fd866479bf0d1f2d032f906ac7ed95b6f8a43