fix: don't mess with values that reference custom props

[jquense]

Ran into this on a gatsby site. shouldn't try and fix values that are custom properties

[luisrudge]

Released in 4.2.0

[luisrudge]

@jquense thanks for the PR! 🎉

[Timer]

Why are the values untouched?

Input:

.flex-parsing {
  flex: 0 0 calc(50% - var(--vertical-gutter));
}

Output before this PR:

.flex-parsing {
  flex-grow: 0;
  flex-shrink: 0;
  flex-basis: calc(50% - var(--vertical-gutter);
}

We seem to be missing a closing parenthesis.

Output after this PR:

.flex-parsing {
  flex: 0 0 calc(50% - var(--vertical-gutter));
}

[luisrudge]

@Timer can you send a PR with a failing test + the fix? Thanks!

[Timer]

@jquense were you targeting a specific issue or was this a workaround for the closing parenthesis issue?

I can send a PR if you confirm this was a workaround and not the intended bug fix!

[jquense]

It targets a specific issue. This:

flex: var(--flex);

was being incorrectly converted to flex: var(--flex) 1; (note the 1)

What exactly is this breaking for you? The example you gave looks likes it's actually fixing an unrelated bug in your code by adding the missing paren? I'm not sure why it would add them tho, since it's not touching the value at all

[Timer]

I believe you misread the code example, this plugin is removing the paren and causing one to be missing.

If we forget this PR for a second, this was the observed behavior:

/* input */
.flex-parsing {
  flex: 0 0 calc(50% - var(--vertical-gutter));
}

/* output */
.flex-parsing {
  flex-grow: 0;
  flex-shrink: 0;
  flex-basis: calc(50% - var(--vertical-gutter); /* <-- note it dropped a closing paren */
}

[jquense]

i'm either reading it wrong or it's written backwards...In your first post it looks like the "Output before this PR:" is missing the the paren and "Output after this PR:" contains it

In any case, the bug is a bit surprising since this change only prevents the plugin from touching a value, it doesn't process them at all. It ends up following the same path as if it was 'none'. We should fix it tho!

[Timer]

Aah, I was saying the output after this PR "fixed" it by completely disabling the flexbug correction. But it doesn't seem like the desired behavior (to be disabled for this case).

From my understanding, your PR was meant to fix this case:

* { flex: var(--flex); }

But it accidentally disabled the transform for this case (where var is unrelated to flex attributes):

* { flex: 0 0 calc(50% - var(--vertical-gutter)); }

[stof]

@Timer but the "fixed" version of this does not contain any fix anyway, as it sets exactly the same values than the longhand.

[Timer]

Can you elaborate on what you mean @stof?