Skip to content

Draw the three printing sites the client now knows about (GRYT-913) - #396

Closed
sivert-io wants to merge 1 commit into
mainfrom
claude/GRYT-913-client-print-icons
Closed

Draw the three printing sites the client now knows about (GRYT-913)#396
sivert-io wants to merge 1 commit into
mainfrom
claude/GRYT-913-client-print-icons

Conversation

@sivert-io

Copy link
Copy Markdown
Member

main is red and has been since #390 — three commits. check-embed-icons refuses a provider @gryt/core names with no artwork here:

providers in @gryt/core with no icon here: makerworld, printables, thingiverse

My doing. core#10 added the three providers, #390 moved the client to @gryt/core 0.5.0, and I put the artwork in core#11 rather than here — because core#9 had moved every logo into the package as path data on the same day, and I read that as this file being on its way out.

It is on its way out. It is not out yet: CardSite still reads PROVIDER_ICONS, so until it reads getProviderLogo instead, a provider with no entry here is a failing check and a missing logo.

Three entries. The import list is re-wrapped because the autofix left it ragged. MakerWorld wears Bambu Lab's mark — the same reason its provider entry wears their green.

Verification

embed icons: ok (76 providers, all drawn)

yarn lint (tsc -b + eslint, --max-warnings 0) passes, as do test:card-byline, test:server-notice and test:identity-certificate. Confirmed against the installed @gryt/core 0.6.0:

provider: makerworld | MakerWorld | #00AE42
detail:   "old vikings jewelry box"
logo makerworld   present (150 chars)
logo printables   present (64 chars)
logo thingiverse  present (563 chars)

Follow-up, deliberately not here

CardSite reading getProviderLogo from the package would delete this file and the react-icons dependency behind it, and would give the phone the same logos — core#9's whole point. That is a bigger change than a red main should wait for, so it wants its own PR.

🤖 Generated with Claude Code

main is red, and has been since #390. `check-embed-icons` refuses a provider
`@gryt/core` names with no artwork here:

    providers in @gryt/core with no icon here: makerworld, printables, thingiverse

My doing. core#10 added the three providers, #390 moved the client to
`@gryt/core` 0.5.0, and the artwork went into core#11 rather than here —
because core#9 had moved every logo into the package as path data on the same
day, and I took that to mean this file was on its way out.

It is on its way out, but it is not out yet: `CardSite` still reads
`PROVIDER_ICONS`, so until it reads `getProviderLogo` instead, a provider
without an entry here is a failing check and a missing logo.

Three entries, and the import list re-wrapped because the autofix left it
ragged. MakerWorld wears Bambu Lab's mark, the same reason its provider entry
wears their green.

Follow-up worth doing separately: `CardSite` reading `getProviderLogo` from the
package would delete this file and the `react-icons` dependency behind it, and
would give the phone the same logos. That is core#9's whole point and it is a
bigger change than a red main should wait for.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@sivert-io

Copy link
Copy Markdown
Member Author

Superseded by #395, which landed the proper fix ten minutes after this was opened: CardSite now reads getProviderLogo from @gryt/core, and embedProviderIcons.ts and check-embed-icons.mjs are gone.

This adds three entries to a file that no longer exists, so there is nothing here worth keeping. #395 is the better answer to the same red main — it removes the second source of truth rather than topping it up.

The logos themselves are already in the package (core#11), so MakerWorld, Printables and Thingiverse draw correctly on main today.

@sivert-io sivert-io closed this Sep 4, 2026
@sivert-io
sivert-io deleted the claude/GRYT-913-client-print-icons branch September 4, 2026 19:51
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