Copy `--features` flag from Typst

[Andrew15-5]

Description

Add --features from typst compile to have access to a11y-extras's API (or html's API).

Alternative Solutions

None

Additional Context

Using https://typst.app/docs/reference/pdf/header-cell/ fails the compilation.

[tingerrr]

I think this is kind of a duplicate of #171 and #200, mainly because the flag in itself doesn't do much, it's the actual target support that's missing. Perhaps this can be reused as a meta issue about features in general though.

[Andrew15-5]

From a user/API perspective, this is a unique feature request. I did not find a single mention of this flag. HTML is not the main use case.

[tingerrr]

The reason I don't mention a flag anywhere is because it makes no sense for testing, you can't expect a user to run tytanic for each variation of features and targets they have tests for and carefully filter out those that don't need or use that target/feature.

[Andrew15-5]

Adding the flag for the sake of adding is not the point. If your package/template requires any feature (currently, 2 tops), i.e., uses an API behind a feature flag, Tytanic will be useless as you can't compile anything without the ability to enable a feature. The reason is not to blindly mix and match, the reason is if you know for a fact that you need to enable a feature. I hope this clears something.

[tingerrr]

No, it does not clear much up, how do you expect this to work? The flag enables the feature for all tests? Only some of them? How does this influence tests which the deliberately fail with these tests?

My point is that, requesting the ability to enable a feature like HTML export or additional a11y features make sense, but using a CLI flag to enable then makes none to me. I would instead use test annotations to enable them on a per-test basis.

[Andrew15-5]

Got it. Okay, the per-test thing, I don't care, simply because, as Laurenz said in typst/typst#7472 (comment), the features are purely additive, as such it doesn't make much sense to provide an option to tweak this per-test. You can enable all (2) features for all tests and nothing will change, if the features are not used.

IMO, a good API would be a CLI flag plus tool.tytanic.default.features = [] in the typst.toml.

I'm not sure if it's a good idea for version migration/compatibility, but maybe just permanently enable all features. This won't change any API, but will enable tests to work with special feature-gated API. I.e., it would just work, like magic.

[tingerrr]

as such it doesn't make much sense to provide an option to tweak this per-test

It sure does, if your test changes behavior depending on the enabled features, as is often the case with HTML.

[Andrew15-5]

The HTML feature does not change the behavior, you must change the output target to HTML in order see any changes.

[tingerrr]

But there is no guarantee of all features staying that way, we can't just enable all features for all tests and call it a day.

I'm willing to add switches and toggles for this (a config option too), but I don't see a point in adding an override on the CLI, because these are deliberately behind feature gates due to their unstable nature. Tytanic should not fail your CI from being updated itself, but such a blunt invocation-wide switch makes it able to.