Open tingerrr opened 1 month ago
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?
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.
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
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.
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.
With respect to https://github.com/typst-community/valkyrie/issues/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.
For coercion of version, can you give some examples of inputs you'd expect a coercion function to correctly convert to version?
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.
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.