Give __unstable__loadDesignSystem a stable name for downstream tooling

[johncarmack1984]

prettier-plugin-tailwindcss is built on a name that says don't build on this. src/versions/v4.ts calls __unstable__loadDesignSystem on whichever tailwindcss the user has installed, then design.getClassOrder(classList). That's the whole dependency. The plugin even declares its own one-method DesignSystem interface for it.

Same name, same two calls, elsewhere:

• tailwindcss canonicalize in @tailwindcss/cli, through @tailwindcss/node (whose wrapper already adds the default loadModule / loadStylesheet that Expose minimal `getClassOrder` API without requiring `__unstable__loadDesignSystem` #17804 asked for, under the same unstable name)
• the IntelliSense language server, which feature-detects the name before calling it
• oxfmt, through the plugin's /sorter entry point
• outside the org: tailwind-merge, a handful of ESLint and oxlint plugins, tailwind-api-utils

So in practice the surface is public, but two of tailwindlabs' own tools already disagree on top of it. tailwindcss@4.3.3, plugin 0.8.1, fresh project, no stylesheet:

input:        zzz-unknown p-4 mmm-unknown flex aaa-unknown
canonicalize: aaa-unknown mmm-unknown zzz-unknown flex p-4
prettier:     zzz-unknown mmm-unknown aaa-unknown flex p-4

Known classes agree. Unknown ones: the CLI alphabetizes, the plugin keeps source order. That's fine, sorting policy can stay with consumers (the comment in sort.test.ts says exactly that). The point is what everyone shares underneath: the loader and getClassOrder.

So, my proposal, kept small on purpose:

• export loadDesignSystem from tailwindcss, and keep __unstable__loadDesignSystem as an alias so nothing breaks
• export the DesignSystem type (today everyone writes Awaited<ReturnType<typeof __unstable__loadDesignSystem>>, the CLI included)
• mirror both in @tailwindcss/node
• the stable promise covers the loader's name and signature, and getClassOrder's signature: (classes: string[]) => [string, bigint | null][]. The rest of DesignSystem stays as unstable as you want it.

I know the prefix is deliberate. The object changes (eight members added to DesignSystem since 4.0) and core does no I/O on its own. Neither has to change. The two things I'm proposing to hold still haven't moved since before 4.0: the loader's signature last changed in #14150 (August 2024), and getClassOrder's hasn't since the v4 codebase landed.

#17804 asked for roughly this in April 2025. In #19092, @philipp-spiess said the core API "is not considered stable for now" and invited people to "help us shape it". If that's still open, I'd love to take you up on it. :)

How I got here: I've recently worked on the Tailwind presets in Biome's useSortedClasses. The generator already calls __unstable__loadDesignSystem to enumerate utilities. The one thing it still scrapes out of tailwind's dist is property-order, and that's a different ask I'm tracking in biomejs/biome#11849. This one is just the name.

I have the diff on this branch. It's two commits, two source files, tests, and a changelog line. The type export is its own commit, so it can be dropped on its own.

Happy to open it as a PR, or reshape it as needed. :)