Skip to content

feat: add Format constants for convert media types, including JXL - #38

Open
Sreini wants to merge 2 commits into
masterfrom
feat/jxl-format
Open

Sreini wants to merge 2 commits into
masterfrom
feat/jxl-format

Conversation

@Sreini

@Sreini Sreini commented Sep 3, 2026

Copy link
Copy Markdown
Contributor

Adds a Format namespace of media-type constants so the types accepted by
convert are discoverable via autocomplete — including JPEG XL
(image/jxl), which the API already accepts but no client surfaced.

image/jxl is already in the API allowlist (apps/api/src/schemas/optimizations.ts
and apps/opt-api/src/constants/content-types.ts), so this is a client-side
discoverability change only. There is no API-side work outstanding.

Members

WEBP, PNG, JPEG, JPG, AVIF, JXL, ANY (*/*) — mirroring the
API allowlist exactly.

Why string constants and not an enum

The JSON body has to carry the media type verbatim. A language-level enum
serializes as its name or ordinal, not image/jxl. String constants also keep
this fully backward compatible: callers passing raw strings are unaffected.

Verification

Full suite green locally: mvn test → 94 tests, 0 failures, including 3 new FormatTest cases.

Part of a coordinated change across all six Tinify client libraries, so the
same Format API is available in each.

Adds a Format namespace of media-type string constants so the types
accepted by convert() are discoverable via autocomplete, including
JPEG XL (image/jxl), which the API already accepts.

String constants rather than a language-level enum: the JSON body must
carry the media type verbatim, and an enum would serialize as its name.
Existing callers passing raw strings are unaffected.
image/jpg and image/jpeg are two distinct values the API accepts, so
describing JPG as an alias was misleading: the constants are not equal.
@Sreini

Sreini commented Oct 31, 2026

Copy link
Copy Markdown
Contributor Author

Heads-up: master itself is currently red in CI, independent of this PR.

Every Maven job now fails at POM parsing, before any compilation:

[ERROR] 'build.plugins.plugin.(groupId:artifactId)' must be unique but found
        duplicate declaration of plugin org.apache.maven.plugins:maven-dependency-plugin
        @ line 295, column 21

pom.xml declares maven-dependency-plugin twice, at line 200 and line 297. That duplicate is pre-existing on master (introduced in 897291f "Fixed transient dependencies for okhttp"); this PR does not touch pom.xml at all.

Verified with a throwaway branch at master's exact tip, zero changes (since deleted): 4 failures, 22 cancelled, 0 passes, same line 295 error.

Why now and not in September, when this PR was green across 64 checks: older Maven treated a duplicate plugin declaration as a warning, newer Maven treats it as a build error. The CI setup does not pin a Maven version, so the runner image moved underneath the repo.

Fix is to delete one of the two maven-dependency-plugin blocks. I have deliberately left it out of this PR, since it is unrelated to the Format change and affects every branch — happy to send it as its own PR if you'd like.

Locally on Maven 3.9.15 (which still only warns) the full suite passes: 94 tests, 0 failures, including the 3 FormatTest cases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant