Latest Results
Docs: Show what else belongs in the tw-merge file and align the tone on the recommendation
The previous commit recommended setting `twMerge` up in one project-owned file, but the snippets re-exported only `twMerge`. A reader who also uses `twJoin`, `extendTailwindMerge`, or the types had to infer that the same file should carry those too, and the plugin getting-started pages never showed the file after it grows beyond the one-line re-export, which is the whole point of having it. The plugin API references also phrased the same advice as a bare instruction ("Import it from one file you control"), while getting started framed it as a recommendation with a note that importing the runtime directly works too. Feedback from an agent following the Next.js docs in a real project flagged both gaps.
Both plugin getting-started pages now say right after the component example to re-export whatever else you use from the runtime the same way, naming `twJoin` and the `ClassNameValue` type. The rationale paragraph ends in a concrete example of the grown file: it imports `extendTailwindMerge` from the runtime, re-exports `twJoin` from it, and exports a configured `twMerge`, with the note that nothing else in the app changes. The example reuses the `text-style` class group from the API reference so the two pages agree. The API reference sentences in both plugins now say "I recommend importing it through one file you control" so they read as the same recommendation as getting started. For consistency, the library's configuration page gets the same one-line clause about re-exporting `twJoin` from the package, and the configurator's getting-started sentence mentions re-exporting `twJoin` from `tailwind-merge` alongside the generated function, since the generated module itself only exports `twMerge` and `getConfig`. Docs: Recommend importing twMerge from one project-owned file in every package
The library, the Vite plugin, the Next.js plugin, and the configurator all told users to import `twMerge` straight from the package in every component: `tailwind-merge`, `@tailwind-merge/vite/runtime`, `@tailwind-merge/next/runtime`, or the generated configurator module. That works on day one but scatters the dependency across the codebase. For the library, the common trajectory is that a project customizes its Tailwind theme later and then needs a configured merge function, which turns into an edit in every file that imports `twMerge`. For the plugins and the configurator, the same applies to wrapping `twMerge`, layering extensions on the generated configuration, or adopting a future change to the plugin API such as the runtime import path. Only the plugins' shadcn migration diff hinted at a single indirection file, and only for projects that already had a `cn` helper.
Every package's docs now recommend setting `twMerge` up once in a file the project owns, shown as a plain `tw-merge.ts` next to the code without prescribing a directory layout, and importing it from there everywhere else, even when nothing is configured. The canonical explanation is a new "Import `twMerge` from one place" section under "Basic usage" in the library's `configuration.md`: it shows the one-line re-export, explains that a later theme customization then becomes a swap to `extendTailwindMerge` inside that one file, and names wrapping, plugins, and a generated merge function as further reasons. The "when and how to use it" page and the wrapper recipe link to that section, and the recipe's wrapper is now shown as the exported `twMerge` of that file. The wording deliberately stays generic about wrapping instead of suggesting a clsx wrapper, which is rarely useful.
The Vite and Next.js getting-started pages show the re-export file before the component that imports from it, with a short version of the rationale, and their migration steps nudge projects that still import `tailwind-merge` directly into the same single file. Both runtime module references point back to the setup section. The configurator's getting-started page re-exports the generated module from the owned file, since the generated module is a build artifact whose location and format can change, and its compose example is framed as that file with an exported `twMerge`.
AGENTS.md records the convention so future setup instructions and usage examples across packages stay consistent with it. The library's docs-examples test still passes with its assertion count unchanged because no new `twMerge(...) // → ...` examples were added, and the package READMEs stay untouched: the library's is generated at release from `docs/README.md`, which did not need to change. CI: Publish dev builds of the Next.js plugin on every main push
The Next.js package stayed out of the dev-publish jobs while it had no npm trusted publisher, since a publish step without one fails on every push. The one-time bootstrap has happened: 0.0.0-dev.ab12ab17b7fbc861f04300973065b9f1cff9863b is on the registry from a manual publish of the merge commit, and the trusted publisher for the repository's publish workflow is configured.
The dev jobs therefore build, pack-check, upload, stamp, and publish @tailwind-merge/next again alongside the library and the Vite plugin, publishing it last so its exact pin on the same-commit library dev build resolves. The package docs go back to promising a dev build per main commit, and the release guides describe the new-plugin sequence in the past tense for both plugins: manual first publish, trusted publisher, then this wiring. Latest Branches
0%
0%
renovate/actions-setup-node-7.x 0%
feature/add-nextjs-plugin © 2026 CodSpeed Technology