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.
