Add built-in version schema and coercion

[tingerrr]

Add a schema and coercion for the verison type, the coercion should attempt parsing a string into a version before it is validated.

Currently, coercions seem to be infallible pre- or post-transformers, at least in semantics, perhaps a relaxation of this could allow parsing conversions like these to simply be pre-transformers.

[jamesrswift]

Are we talking about semver version strings?

On coercions, they can fail if they return none as that throws spanners into the gears further down which would result in a failure. In that sense therefore, perhaps a version schema could instead be a string schema with a semver coercion that fails if its too far out of spec?

[tingerrr]

I'm not sure, I just think we should have some way of allowing users to go from "0.1.0" to version(0, 1, 0) in an ergonomic way with good error messages.

Parsing author strings into a name email pair would also be a candidate for this kind of parsing coercion.

[jamesrswift]

You had me checking if there was a type for version and I don't know how I've missed it this entire time but there apparently is! I'll read up on it but it sounds like it should be an easy addition

[tingerrr]

I think this may be valid for #10 too, to allow restricting versions to some semver range.

See also #13 in general for some others.

[jamesrswift]

Version schema generator is implemented by #18. I'll make a separate PR for creating the coercions for these individually as they'll likely need a lot more thought and tailoring.

With respect to #10, I think the assertions worth adding are minimum version and maximum version, though I think an assertion that may be more commonly used is a string representation like that which npm uses.

[tingerrr]

With respect to #10, I think the assertions worth adding are minimum version and maximum version, though I think an assertion that may be more commonly used is a string representation like that which npm uses.

I think the usage of ^ and ~ may be too much for Typst as there is no version resolver for it at the moment, we can likely restrict it to

version_requirement ::= { '>=' | '<=' } major [ '.' minor [ '.' patch ] ]

Nothing too fancy, it should be noted that this is a version requirement, not a version itself.

[jamesrswift]

For coercion of version, can you give some examples of inputs you'd expect a coercion function to correctly convert to version?

[tingerrr]

Assuming fallibility is allowed, it would be the inverse of str(version(..args)):

• parse-version("0") -> ok
• parse-version("0.0") -> ok
• parse-version("0.0.0") -> ok
• parse-version("=0.0.0") -> err
• parse-version(">=0.0.0") -> err
• parse-version("0.x.0") -> err
• parse-version("") -> err

Some of these are plain invalid, others are version requirements, not versions.