weapp-tailwindcss-migrate

weapp-tailwindcss migrate

Migrate legacy projects from responsibility boundaries and the build graph; do not layer patches on top of the old configuration.

Workflow

1. Read the manifest, lockfile, Tailwind entry, bundler configuration, PostCSS configuration, and run scripts.
2. Identify the current weapp-tailwindcss/Tailwind/Node/HBuilderX/bundler versions and all generation entries.
3. Read references/v5-migration.md, and migrate in the order of dependencies, entries, plugins, target platforms, and verification.
4. Delete the old patch and duplicate Tailwind generators in the same build, then register the current WeappTailwindcss。
5. Legacy CLI users migrate to the standalone @weapp-tailwindcss/cli 5.x, and move the init, preprocessor, and directory scanning responsibilities back into the project build chain.
6. Migrate the Tailwind entry to pure CSS, ensure it is actually imported, and write all real entries as absolute cssEntries。
7. Remove the old logic of “always disabling H5/Web”; let the generator automatically detect the Web target.
8. Verify the migration with one clean build, one newly added arbitrary-value class, and one HMR update; the App target must be checked in a real runtime.

Migration discipline

• First record the old configuration and a rollback commit; do not mass-delete PostCSS or framework plugins whose ownership cannot be confirmed.
• Only delete duplicate entries responsible for Tailwind generation; separate builds of standalone Web apps may continue to use the official Tailwind plugin.
• Do not use alwaysEscape or expand string scanning to mask outdated classNameSet。
• Do not equate a successful build with a successful migration; at minimum check the target platform CSS, template/JS safe class, and newly added candidates.

Output requirements

Output the pre-migration diagnosis, deletion/retention list, per-file diff, verification results, and rollback steps, and flag any device or IDE environments that still require manual verification.