Any TDF, one mobile design system published as three framework libraries

One design system, three framework native libraries

The pitch takes one line to state:

One shared design system. Three framework-native mobile component libraries.

Any TDF is a mobile first component system for Svelte, React and Vue. The repository is a monorepo published under the @any-tdf scope, with the three consumer packages named after their framework: stdf for Svelte, rtdf for React and vtdf for Vue. Each has its own documentation site and its own demo site, and the project itself lives at any-tdf.dev.

The audience is a specific kind of team. If you ship one mobile product and need the same interface on three frameworks, the usual outcome is three component libraries that drift apart in spacing, tone and behaviour within a couple of quarters. Any TDF is an attempt to hold the product decisions in one place while letting each framework keep its own idioms.

It is worth noting what the project is not. The README states plainly that this is not a cross framework wrapper and not a single runtime hidden behind adapters. There is no common runtime that renders and no adapter layer that translates.

The alternatives for the same problem are the usual ones. A headless component library plus a Tailwind styling layer gives you one implementation of behaviour and unstyled markup, which is lighter but leaves visual consistency to each team. Three separate libraries give full idiomatic fit and three times the maintenance. Any TDF sits between the two, closer to the second in feel, since each package is a real component library with its own components.

What is shared and what stays native to each framework

The README draws the line explicitly. The three libraries share product behavior, visual language, themes, locale data, public types, documentation structure and accessibility rules, while preserving the rendering model and composition patterns of each framework.

That division is the design idea, and each half has a concrete expression. On the Svelte side, STDF exposes components, snippets, actions and transitions. On the React side, RTDF exposes components, props, render functions, hooks and providers. On the Vue side, VTDF exposes components, slots, events and composables.

So the shared layer is not a component layer. It is the specification: the same behaviour, the same tokens, the same locale bundles and the same accessibility expectations, re-expressed in the idioms each framework community uses. A team that knows Svelte gets snippets and actions, a team that knows React gets hooks and providers, and both get the same component behaviour.

The pay-off is consistency at the level that is expensive to change later. Behaviour and locale data are where copies drift fastest, because each copy is updated when someone remembers. Public types being shared also means an API change has to be applied three times in the same commit, which is a cost the maintainers took on themselves.

The cost on the adopter's side is that you get three implementations to read rather than one, and each framework's components are only idiomatic in its own ecosystem.

The package set beyond the three component libraries

The monorepo workspace globs show how the repository is organised, with apps, extensions, packages, per package docs and a skills directory all sharing one workspace:

    "name": "@any-tdf/monorepo",
    "private": true,
    "license": "MIT",
    "workspaces": {
        "packages": [
            "apps/*",
            "extensions/*",
            "packages/*",
            "packages/*/docs",
            "packages/skills/*"
        ],

Alongside the three component libraries, the npm scope carries the supporting packages visible in the README badges. There is @any-tdf/common for the shared layer, create-any-tdf for scaffolding a new project, and two Vite plugins, @any-tdf/vite-plugin-svg-symbol for SVG symbol handling and @any-tdf/vite-plugin-md-ts for Markdown typed as TypeScript. There are also motion packages for React and Vue and confetti packages for React and Vue.

Two of those deserve a comment. The scaffold tool is what a team would reach for first, because it sets up a project with the right configuration and the right version of the library. The motion packages exist because animation is the part of a component library that most often leaks framework specific API into user code, and offering per framework packages keeps that leak out of the shared abstraction.

The extensions directory is where the VS Code extension lives, with its own publish workflow, and the skills directory suggests the project also ships agent facing instructions alongside the components.

The build stack: Bun, Turbo, Tailwind 4 and a peer version matrix

The dependency catalog in the root package.json shows the stack the project builds on. Bun is the runtime and package manager, with a bun.lock and a bunfig.toml in the repository root, and Turbo is the task runner configured through turbo.json. Tailwind CSS 4 appears both as a workspace dependency and as a peer requirement, and the project uses Vite 8 for its apps.

The peer catalog is the part an adopter reads, because it defines what your application must already provide:

            "peer": {
                "react": "^18.0.0 || ^19.0.0",
                "react-dom": "^18.0.0 || ^19.0.0",
                "svelte": "^5.0.0",
                "tailwindcss": "^4.0.0",
                "vue": "^3.5.0"
            },

Three things follow. The libraries expect current framework majors rather than the older ones, so React 18 is accepted but React 17 is not, Svelte 5 means the runes based model, and Vue 3.5 means the modern composition API. Tailwind CSS 4 is a peer dependency rather than a bundled one, which keeps the styling tool in your hands.

TypeScript is handled with some ambition. The catalog carries several parallel toolchains, including a native TypeScript build published under an alias and a separate Vue native bridge, alongside the standard compiler at version 6. That is more machinery than a component library strictly needs, and it is worth asking the maintainers what it buys before you rely on it.

Changesets are in use for versioning, which is how the three packages can move on independent schedules instead of being locked to one monorepo version.

Where Any TDF is the wrong choice

The clearest limitation comes straight from the release list. On 2026-10-01 the Svelte package stdf moved to 3.0.0, while rtdf and vtdf were both published at 0.0.1. A zero point zero one version is an initial release in anyone's reading, and it means the React and Vue libraries are the young parts of the family while the Svelte one has had three major iterations.

That asymmetry is the whole adoption question in one line. If you are on Svelte, you are choosing the mature branch of a young project. If you are on React or Vue, you are choosing a first release that has not yet survived a breaking change cycle.

The second limitation is scope. The system is described as mobile first, and mobile first component libraries make different choices about density, hit targets and platform behaviour than desktop libraries do. A team building an internal desktop admin tool will find the mobile orientation a poor fit even if the visual language is fine.

The third is Tailwind. Tailwind CSS 4 being a peer dependency means the libraries are tied to a utility first styling model. That is a reasonable choice in 2026, but it rules out teams on other styling approaches, and it means the shared visual language is expressed in Tailwind terms, which is where the three packages must stay in step with each other.

The fourth is the shared runtime surface of a design system with three implementations. Behaviour that must match across frameworks has to be implemented three times, and any bug in the shared specification is now three bugs. The README's own framing of the approach as parallel development of three packages confirms that cost is being paid deliberately.

The last practical point is the release channels. The repository has CI, npm publish, VS Code publish and release workflows, and its README carries translations in ten languages. That infrastructure is a sign of long term intent, but it also means the project is young enough that its workflows have not been observed over many years.

Maintenance, licensing and a sensible adoption path

The last push to the repository was on 2026-10-19, so the work is current, and the three packages were published together on 2026-10-01 with stdf at 3.0.0 and the other two at 0.0.1. A project with that release history is one to watch rather than one to pin your production roadmap to.

The licence is MIT across the monorepo, which the root package.json records for the private workspace and which governs the published packages. For a commercial product that means no copyleft obligation on your own code and no requirement to open source your application. That is a licensing observation, not legal advice, and the LICENSE file in the repository is the text to read.

A sensible adoption path looks like this. Start with the scaffold tool for your framework and build one real screen with the library, then check the components you plan to use against the documented behaviour rather than against the demo, since the demos are built to show the happy path. Use the shared types to catch drift early, and if you are shipping on two or three frameworks, decide deliberately whether you accept the 0.0.1 packages or wait for their first stable release.

The design decision to reuse one specification across three frameworks is a good one on paper, and the numbers to watch are simple: the version of the package for your framework, and whether the components you need are documented for it. Everything else in the repository, from the motion packages to the VS Code extension, is a bonus on top of those two checks.

Editorial conclusion

Any TDF suits a team that has to ship the same mobile product on more than one frontend and would rather maintain one design decision set than three, and it is a poor fit for a desktop first product, a team on Angular, or anyone who wants a single import path that works in every framework. Verify first which of the three packages your stack needs and whether that package has a release you would actually depend on, because stdf was at 3.0.0 while rtdf and vtdf were still at 0.0.1 on 2026-10-01, then confirm the peer requirements in the monorepo catalog, Tailwind CSS 4, React 18 or 19, Svelte 5 and Vue 3.5, match your build before you start.

Frequently asked questions

Official sources

1. any-tdf/any-tdf on GitHub
2. License: MIT
3. Project website
4. README
5. Releases