Question about what qualifies as a value

[AKST]

Hi, so I wrote a PostCSS plugin for responsive values, and where you define a couple of branches for a value for different media queries with intended use looking like this

@value fontSize: media-value(
  case: "a" as: "18px",
  case: "b" as: "16px",
  case: "c" as: "16px",
  case: "d" as: "14px",
  else: "14px",
);

.fontDef {
  font-size: fontSize;
}

I would have expected without adding my plugin css modules would have copied the value of fontSize into the rule fontDef and you would have output like:

.fontDef {
  font-size: media-value(
    case: "a" as: "18px",
    case: "b" as: "16px",
    case: "c" as: "16px",
    case: "d" as: "14px",
    else: "14px",
  );
}

So when my plugin passed over it, it could expand the value over the rule so I would get

.fontDef {
  font-size: 14px;
}

@media a { .fontDef { font-size: 18px; } }
@media b { .fontDef { font-size: 16px; } }
@media c { .fontDef { font-size: 16px; } }
@media d { .fontDef { font-size: 14px; } }

But it turns out the CSS remains completely untransformed from the original CSS, am I missing something? Is because the value defined is too gnarly for CSS Modules to interpret?

---

Update

So it turns out if I remove all new lines from the value the output is correct. So if it's like this....

@value fontSize: media-value(case: "a" as: "18px", case: "b" as: "16px", case: "c" as: "16px", case: "d" as: "14px", else: "14px");

.fontDef {
  font-size: fontSize;
}

CSS Modules transforms the value into this

.fontDef {
  font-size: media-value(case: "a" as: "18px", case: "b" as: "16px", case: "c" as: "16px", case: "d" as: "14px", else: "14px");
}

---

Questions! (Update 2)

1. Does this qualify as a bug? If so are you open to pull requests :)
2. Would a valid workaround be...
   • Having a plugin in the before plugin group, to strip the newlines from @value AtRules
   • Then having the original PostCSS Plugin in the after plugin group in the config to operate on the version with new lines stripped
   • Would this work in the mean time?

[dfreeman]

@AKST Sorry, I know I owe you an answer here—I've been swamped recently, but I'm hoping to have a chance to dig in on this in the next couple days.

[AKST]

No worries, but thanks for the heads up!

[dfreeman]

1. Does this qualify as a bug? If so are you open to pull requests :)

@AKST I'd personally call it a bug, though probably not one in this repo :)
You may want to check out postcss-modules-values, which is the plugin responsible for doing @value stuff (it looks like it's been renamed to postcss-icss-values?)

2. Would a valid workaround be...

• Having a plugin in the before plugin group, to strip the newlines from @value AtRules
• Then having the original PostCSS Plugin in the after plugin group in the config to operate on the version with new lines stripped
• Would this work in the mean time?

That sounds like it ought to work. You could even bundle up your pair of PostCSS plugins into an ember-css-modules plugin that ensures they get applied the right way in consumers :)

[AKST]

Cheers, @dfreeman! The work around I suggested did work :) But I'll look into your plugin suggestion (I just haven't had much luck building ember-cli plugins in the past 😅), and try and follow up on opening on the postcss-icss-values repo.

---

Edit:

Thanks for your help by the way (and your add-on 😄)

I've made the issue in the other repo, I'm not entirely sure what you want to do this with this issue, but as far as I'm concerned all my questions have been addressed, and until the upstream issue (is first considered an issue) and addressed there isn't anything to action on

[dfreeman]

I'll go ahead and close out this issue for now, and I'll keep an eye on the upstream one to see how things progress.

Feel free to ping me on Slack if you want a hand puzzling through the plugin stuff—I'm happy to help 🙂