Was it really necessary to break all existing apps using `npx @tailwindcss`?
It's an easy enough change to `npx @tailwindcss/cli` but we now have to go back and update all Apps and templates and since it uses v4 we now have to test every App to see if anything's broken with a v4 major release.
Given its massive install base, surprised they wouldn't maintain backward compatibility with v3 and have an explicit opt-in upgrade path to v4.
Edit:
v4 did actually break all our Tailwind Apps which doesn't support `@import "tailwindcss"`, likely because we use `npx tailwindcss` without any local npm dependencies. Trying to use the existing v3 `@tailwind components` renders a useless app.css. Only solution atm is to explicitly use v3 and change all our build scripts to use `npx tailwindcss@v3`.
You’re doing something silly living without a lock file to use a tool as part of your build process. Why don’t you actually include the version of the tool you want in your dev dependencies + lock file? That way, you don’t get broken. We’ve had the solution to this problem - lock files - for 15ish years, since Ruby’s `bundle` introduced it.
Not everything is a node App. We don't have a lock file because we don't have any local npm dependencies (as already mentioned). We're using `npx tailwindcss` as-is.
You clearly have a dependency on tailwindcss (if it can break you, you depend on it), and are using npm to fetch it (npx uses npm internally, they are installed together) so you can easily solve your problem by adding a couple json files with some version numbers in them. npx will pick up and use the version from your package.json, so no workflow change other than running `npm install …` once to generate package.json for your preferred semver specifier, and package-lock.json to guarantee your builds use a known-good version from now on.
I don’t care how you do it, just make getting your dependencies deterministic based on files committed to your repo!
Happily the Tailwind hex package encourages you configure a fixed version number, so you’ll never get surprise breakage as long as you’re committing your mix.lock file as well.
I’m only suggesting package.json/package-lock.json because their projects are already using the npm ecosystem to fetch the tailwind dependency. A Makefile that does `curl $TAILWIND_GITHUB_RELEASE_URL -o ./departing/tailwind` is fine too (this is what Tailwind.hex is doing under the hood).
FFS we don't have local dependencies. Which means we don't have any local node_modules and have never ran npm install (there are no dependencies to install!). There is no lock file or dependencies.
Our Apps don't have any npm dependencies nor needs to run npm install by design, we're not going to start now, as already stated we're switching to `tailwindcss@v3` instead.
The point is this was a documented supported use-case which all our non node.js Apps used, which have now broken as a result of this release.
I also use tailwindcss in a non-node project, but use npm package / lock files to easily lock javascript / css dependencies and make renovate able to update them for me.
I've linked to why. We prefer #NoBuild solutions where we'd only use local npm deps/node_modules if we absolutely have to, and for non JS Apps we don't.
The node_modules folder is still somewhere on your system (~/.npm/_npx probably?) containing the same tailwindcss dependency files, but if it helps you sleep easier at night it’s okay to pretend it doesn’t exist.
No kidding, I thought global tools worked with fairy cloud dust, now I wont be able to sleep! But knowing there's not a going to be a bloated node_modules folder and local dependencies running different versions unnecessarily maintained in every project will definitely help.
It's an easy enough change to `npx @tailwindcss/cli` but we now have to go back and update all Apps and templates and since it uses v4 we now have to test every App to see if anything's broken with a v4 major release.
Given its massive install base, surprised they wouldn't maintain backward compatibility with v3 and have an explicit opt-in upgrade path to v4.
Edit:
v4 did actually break all our Tailwind Apps which doesn't support `@import "tailwindcss"`, likely because we use `npx tailwindcss` without any local npm dependencies. Trying to use the existing v3 `@tailwind components` renders a useless app.css. Only solution atm is to explicitly use v3 and change all our build scripts to use `npx tailwindcss@v3`.