{
  "id": 9385276,
  "title": "One Icon Catalog, Many Delivery Surfaces",
  "url": "https://urgent.news/2026/09/23/one-icon-catalog-many-delivery-surfaces",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-23T18:00:18.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/svgicons/one-icon-catalog-many-delivery-surfaces-157j"
  },
  "original_language": "en",
  "account": "In modern software development, a single icon system can be utilized across various packages and platforms. For instance, a React package might be at version 3.4.1, while its Vue counterpart is at version 2.8.0, and the CLI is at version 1.6.2. While this diversity in package versions is common, a more critical factor to consider is the icon catalog version. Package versions and catalog versions are distinct concepts, and package updates often introduce changes unrelated to the icons themselves.\n\nTo address this, a better approach is to use a consistent catalog version across all tools. For example, a React package at version 3.4.1 would correspond to Catalog 42, a Vue package at version 2.8.0 would also use Catalog 42, and the CLI would use Catalog 42 as well. This ensures that even if the underlying software versions differ, the icon content remains consistent.\n\nHowever, maintaining this consistency can be challenging. For instance, if an icon is updated from \"arrow-next\" to \"arrow-right,\" the geometry may remain the same, but if the API refers to it as \"arrow-right\" while the CLI still uses the old name, the two surfaces have diverged. Such metadata drift can be as disruptive as SVG drift, the graphical representation of the icons.\n\nTo prevent this, each delivery surface, including websites, APIs, and MCP servers, should expose three key values: catalogVersion, catalogHash, and generatedAt. These values allow for easy verification of synchronization between different tools. If all surfaces report the same catalogVersion, catalogHash, and generatedAt, it indicates that they are indeed using the same icon catalog.\n\nImplementing this approach does not require every output to be built with the same technology. The crucial aspect is that every output starts from the same catalog state. This practice is particularly important when machines consume the library, as it ensures consistent behavior across different tools.\n\nFor automated workflows, having a synchronized catalog is essential. For example, a workflow that involves searching for a database icon, selecting \"database-cloud,\" requesting its SVG through an API, and exporting it through a CLI would be unpredictable if the search, API, and CLI are not based on the same catalog revision.\n\nMoreover, this concept extends to AI agents that can programmatically search, inspect, and retrieve icons. Consistency between different surfaces becomes a critical part of the API contract, ensuring reliable interactions between software components.\n\nFinally, it's important to note that software versions and catalog versions are not necessarily the same. Two different package versions can still expose the exact same icon catalog, and a small piece of metadata like catalogVersion, catalogHash, and generatedAt can prevent confusion and ensure seamless integration across various tools and platforms.",
  "summary": "An icon system can have many versions. Your React package may be 3.4.1 . Your Vue package may be 2.8.0 . Your CLI may be 1.6.2 . That is not a problem. The problem starts when they no longer expose the same icon catalog . Package version and catalog version are different things Software packages evolve for many reasons: bug fixes framework compatibility build changes new commands performance…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}