`goog.getCssName` not rewriting classes

Hi there esteemed Closure Compiler authors,

I am running into an issue where CSS class name rewriting doesn’t seem to work. I am invoking the compiler from rules_closure using Bazel, and I can confirm the CSS rewrite map properly gets generated (from GSS), and properly gets passed to the Closure Compiler as an input.

However, I have tried manually breaking the syntax in the rewrite map, and it produces no compiler warning or error. This leads me to believe the map is not getting included somehow, perhaps because of dependencies=STRICT, but I don’t think I’ve read anywhere that I need to goog.provide the rewrite map to keep it around.

In any case, I have filed this over in rules_closure as issue 401, and I am including it here, because as far as I can tell, it doesn’t have anything to do with rules_closure or Bazel:

Given the following Bazel/rules_closure setup (WORKSPACE and related wiring omitted):

sample.soy:

{namespace sample.tpl}

{template .sample}
  <div class="{css('hello')}">
    <b>hi</b>
  </div>
{/template}

sample.css:

.hello {
    background: blue;
}

sample.js:

goog.provide('sample');
const soy = goog.require('goog.soy');
const tpl = goog.require('sample.tpl');

const docFrag = document.createDocumentFragment();
const el = soy.renderAsElement(
  docFrag,
  tpl.sample,
  {},
  {});

document.body.appendChild(docFrag);

BUILD.bazel:

closure_css_library(
  name = "sample-css",
  srcs = ["sample.css"],
)

closure_js_template_library(
  name = "sample-tpl",
  srcs = ["sample.soy"],
  deps = [":sample-css"],
)

closure_css_binary(
  name = "sample-styles",
  deps = [":sample-css"],
)

closure_js_library(
  name = "sample-js",
  srcs = ["sample.js"],
  deps = [
    ":sample-tpl",
    "@io_bazel_rules_closure//closure/library/soy:soy",
  ]
)

closure_js_binary(
    name = "sample",
    debug = False,
    entry_points = ["sample"],
    deps = [":sample-js"],
    css = ":sample-styles",
)

When I build and run the resulting JS, the template renders, but it renders with the original CSS names, whereas, the CSS has been rewritten. This breaks styles, of course.

Digging into the intermediates: bazel-out/darwin-fastbuild/bin/.../sample.js-0.params:

external/com_google_javascript_incremental_dom/.../lots.js
external/com_google_javascript_incremental_dom/.../of.js
external/com_google_javascript_incremental_dom/.../sources.js
...
...
...
bazel-out/darwin-fastbuild/bin/.../sample.css.js
--define=now=true
--define=some=true
--define=defines=true

The last entry in the set of input files, is a file that ends in css.js. Examining that file, it looks like we’re on the money:

goog.setCssNameMapping({
  "material": "a",
  "icons": "b",
  "hidden": "c",
  "mdl": "d",
  "button": "e",
  "no": "f",
  "select": "g",
  "numeric": "h",
// ...

In the generated template file, it seems to know what’s going on (as in, it’s using goog.getCssName):

      incrementalDom.attr('action', '#');
      incrementalDom.attr('class', goog.getCssName('page-welcome--form-module') + ' ' + goog.getCssName('page-welcome--form-account'));

But, in the final output JS, it uses the original classes:

Versions of things: bazel:

Build label: 0.27.0
Build target: bazel-out/darwin-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Mon Jun 17 13:03:58 2019 (1560776638)
Build timestamp: 1560776638
Build timestamp as int: 1560776638

closure-compiler:

Version: v20190528
Built on: 2019-05-29 21:55

macOS:

Version 10.14.5 (macOS Mojave)

[sgammon]

@EatingW well, you’ll love this.

So, we are dispatching closure_js_binary through j2cl_application in our own environment. After modifying j2cl_application to accept **kwargs so I can pass closure_js_binary the styles (PR incoming over there), somehow it builds (as in, J2CL’s dispatch of closure_js_binary seems to fix the goog.soy issues we both ran into).

To make matters even more interesting, it now builds in the sample, and CSS rewriting works as expected. This doesn’t necessarily mean there isn’t an issue, though:

1. This is using the standard JSSRC compiler from Soy, rather than the older idom compiler. We can now upgrade to the new idom compiler, so we’ll do that today and see if it changes things.

2. I already know the older idom compiler is emitting goog.getCssName, so this only complicates things. In both cases, the rewrite map makes it into the compile job, so, as long as it’s compiling JS with a rewrite map (regardless of which template compiler is in play), rewriting should work, but doesn’t.

update: sample repo up at sgammon/css-rewrite-bug, where it demonstrates building with CSS rewriting working. i have it confirmed it works with both template compilers and the dev server, so, i think i can completely rule out closure-compiler on this one.

it seems to me J2CL drastically changes the build flow with rules_closure, and it’s likely that was the culprit. it seems to be fixed now on HEAD, so I’ll post back if i encounter this again.

thank you for your help @EatingW.

[EatingW]

Created internal issue http://b/137135966