Commits
Tarun Sukhani authored cafa1bfd20b
fix(skel): declare tailwindcss so scaffolded frontends can't resolve it from an ancestor node_modules (PF-165)
nuxt-skel declared @nuxtjs/tailwindcss but not tailwindcss itself. Under pnpm's
strict layout the transitively-installed copy is never linked into the app's
frontend/node_modules/, so it is invisible at the project root — and Node's
resolver then walks up the directory tree. On any machine with a node_modules in
an ancestor directory (a $HOME/node_modules is the common case) it can find a
different Tailwind major, and if that copy is v4, `pnpm dev` fails outright:
@nuxtjs/tailwindcss@6 invokes tailwindcss as a PostCSS plugin, which v4 moved to
@tailwindcss/postcss.
The app's dependency graph was already correct — pnpm resolved tailwindcss@3.4.19,
exactly what @nuxtjs/tailwindcss@6.14.0 pins (~3.4.17). It just never became
reachable. This is a phantom dependency: the build uses tailwindcss, nothing
declared it.
The range must be v3. @nuxtjs/tailwindcss is the constraint here, not Nuxt:
6.14.0 is dist-tags.latest with a hard tailwindcss ~3.4.17 dependency and there
is no v7 line, so declaring ^4 would deliberately recreate the crash. ^3.4.17
overlaps the module's own range, so pnpm dedupes to a single copy.
Declaring it changes visibility, not installation — 3.4.19 was already present in
.pnpm/ beforehand. On a machine with no ancestor node_modules the change is inert.
Verified on a machine that reproduces the failure, by scaffolding a fresh app
under $HOME so it was exposed to the same ancestor node_modules:
require.resolve('tailwindcss') -> .../pf165check/frontend/node_modules/.pnpm/
tailwindcss@3.4.19/... (was $HOME, v4.3.1)
pnpm install && pnpm dev -> Nuxt 3.21.10 boots, 0 PostCSS errors, 200
The same scaffold also confirms PF-166's default path is intact: with a stock
conf and no env var the page still renders "(port 9000)".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>