Validate bare values

[RobinMalfait]

This PR validates incoming bare values to ensure we generate CSS that makes sense.

Before this PR, we would generate values such as:

.z-index {
  z-index: index;
}

.flex-foo {
  flex: foo;
}

Which is invalid, after this PR, these vaues would not be generated at all.

[RobinMalfait]

I put the validation for col-span, col-start, col-end, row-span, row-start, and row-end in a separate commit because they can technically almost contain any value. If a "name" is used, then they would refer to named grid areas: https://developer.mozilla.org/en-US/docs/Web/CSS/grid-column-start

/* <custom-ident> value */
grid-column-start: somegridarea;

/* <integer> + <custom-ident> values */
grid-column-start: 2;
grid-column-start: somegridarea 4;

So the question is, do we want to allow anything here, or is it fine to only accept integer values for bare values, e.g.: col-span-123 and if you want to generate values using names that you should use arbitrary values instead?

[adamwathan]

I kinda think just do numbers and use arbitrary values for other stuff 👍🏻

[thecrypticace]

Agree, I think bare values should just be numbers. Feels much simpler to explain that too.

[RobinMalfait]

Alright perfect, than I can keep the commit in there, nice 👍

[thecrypticace]

This looks good. I'm just thinking out loud but I wonder if we can lift this check up a level to before we call handleBareValue? The only oddball out then is aspect-* in which the bare value is {number}/{number} but I'm not sure how we'd want to handle that. Any ideas?

[RobinMalfait]

This looks good. I'm just thinking out loud but I wonder if we can lift this check up a level to before we call handleBareValue? The only oddball out then is aspect-* in which the bare value is {number}/{number} but I'm not sure how we'd want to handle that. Any ideas?

I initially added a validateBareValue function, but then noticed that we already have some validation happening here:

tailwindcss/packages/tailwindcss/src/utilities.ts

Lines 2822 to 2829 in 9fc5aa1

	handleBareValue: ({ value }) => {
	if (!value.endsWith('%')) return null
	let num = Number(value.slice(0, -1))
	// Only 50-200% (inclusive) are valid:
	// https://developer.mozilla.org/en-US/docs/Web/CSS/font-stretch#percentage
	if (Number.isNaN(num) || num < 50 || num > 200) return null
	return value
	},

therefor I inlined it in the handleBareValue function.

I was thinking about providing something like:

{
  validation: ['<number>', '<integer>', '<angle>', 'auto']
}

But then there is an additional layer of indirection going on and we would have to parse those values and what not. So I don't think it's worth it really.

I kinda like that you have full control right now, and bail when using return null.

If anything, I think we could add some functions like isInteger, isNumber that abstracts the common Number.isInteger(Number(value)) related code.

[adamwathan]

Looks good so far, I think missing handling the flex root though, because current alphas generate this for example:

.flex-direction {
  flex: direction;
}

[RobinMalfait]

Looks good so far, I think missing handling the flex root though, because current alphas generate this for example:

.flex-direction {
  flex: direction;
}

Yep handled this one and also for stroke and fill utilities.

[thecrypticace]

one small nit about a comment but otherwise looks good!