Weird parsing when used on Heroku

[eneroth]

Because of the way I've written my prototype web app, CSS gets re-rendered when the project is pushed to Heroku (and dumped in main.css). I noticed that colors get rendered in a really weird way on Heroku. Check it out:

What locally gets rendered as:

  border-color: #6eaedd;
  color: #6eaedd;

On Heroku, gets rendered as:

border-color: red: 110;
  green: 174;
  blue: 221;
  hue: ;
  saturation: ;
  lightness: ;
  alpha: ;;
  color: red: 110;
  green: 174;
  blue: 221;
  hue: ;
  saturation: ;
  lightness: ;
  alpha: ;;

I haven't been able to discern why this happens.

[noprompt]

Colors are currently represented by a record type in garden.colors. Why there would be a problem with the rendering on Heroku is beyond me. Question: does, for example, garden.units/px result in the same sort of output? That is, rendering the magnitude and unit fields as CSS properties. Also are you using the latest version of Garden?

One suggestion might be to use the lein-garden plugin I released earlier this week although haven't announced it. You could use that to autocompile your stylesheet(s) while you work and just push that. The configuration for it is a familiar blend of lein-ring and lein-cljsbuild.

[eneroth]

I agree, it's quite weird and could just as easily represent something weird with the Heroku config, I guess. (px 500) etc. works just fine, it's quite specifically colors that seems to behave this way. Very weird indeed. It's like it is just printing the contents of the record or something.

I'll check out lein-garden! Thanks! Though I might try to find some way of making the (css) call conditional of it being on my machine if I can't work out why this happens. Auto-recompiling the CSS is right now just a case of reloading a namespace, using the same auto-reload function as the rest of the code, which is quite nice.

I'll throw this question at Heroku support as well to see if they have anything to add. Work-arounds are fine for the time being, but if I want to generate some CSS on the fly, while in production, it might be useful to try to resolve this permanently. Or switch host, I guess.

[eneroth]

Oh, and this is on Garden 1.1.2, by the way. I just checked on 1.1.3, though, but the issue remains.

[noprompt]

This sounds like a fairly interesting problem now. I'm perhaps wondering if there is a mistake in the compiler compiler code. Could you give me some more information such as dependencies in your project and maybe an example of the code that produces the bug? I'll see if I can recreate it.

[eneroth]

I've put together a minimal project that reproduces this problem. It uses Hiccup, Garden, and NS-Tracker to auto-regenerate the CSS when on Heroku (thus reproducing the problem). Do you have an Heroku account so that I can give you access to the project?

Edit: added you to the Heroku app.

Edt 2: Turns out that NS-Tracker is completely unnecessary. Heroku regenerates the CSS anyway. However, it doesn't seem to break anything by being there either.

[noprompt]

@eneroth Hey I haven't had time to look in to this issue is it still a problem for you?

[eneroth]

@noprompt Gotcha! Yes, unfortunately I have not been able to resolve the issue.

[eneroth]

I received some information from Heroku:
"I don't know why this is happening, but I can tell that it's triggered by AOT compilation. Disabling AOT compilation by switching to an uberjar made the output go back to the expected #b2b2b2; syntax. Hopefully that lets you debug the problem with Garden further."

[noprompt]

Hey @eneroth I'm going to go ahead and close this since it's been several months now and no one has reported any similar problems. Reopen or let us know if you discovered a solution.