3 ms·

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 an

by mythz 2y ago

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`.

jitl 2y ago
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.
- mythz 2y ago
  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.
  - jitl 2y ago
    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.
    - mythz 2y ago
      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.
      - Aeolun 2y ago
        I find it really hard to not immediately be reminded of this: https://xkcd.com/1172/ https://xkcd.com/1172/
        mythz 2y ago
        We only use npm dependencies and bloated node_modules folders [1] if we absolutely have to and for our non node.js Apps we explicitly don't. [1] https://www.reddit.com/r/ProgrammerHumor/comments/6s0wov/heaviest_objects_in_the_universe/ https://www.reddit.com/r/ProgrammerHumor/comments/6s0wov/hea...
        preisschild 2y ago
        But why not though 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.
        mythz 2y ago
        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.
        jitl 2y ago
  - nejsjsjsbsb 2y ago
    Shove an @ version in it
    - mythz 2y ago
      Yep `npx tailwindcss@v3` is the solution we ended up with. Just had to change this in all our Apps and project templates.
      - nejsjsjsbsb 2y ago
        I wish @-less wasn't be allowed. Like you can do @latest but then human confirm is needed. That way you don't get this problem in scripts.
        jakubmazanec 2y ago
        > then human confirm is needed "Suppress this prompt with the -y or --yes option" [1] [1] https://docs.npmjs.com/cli/v11/commands/npx https://docs.npmjs.com/cli/v11/commands/npx
  - GrzegorzWidla 2y ago
    So why not npx tailwindcss@^3.0.0 (or whatever version was there when you started)?
aembleton 2y ago
> Given its massive install base, surprised they wouldn't maintain backward compatibility with v3 and have an explicit opt-in upgrade path to v4. Given it's a major version change, I'd expect it to create breaking changes, otherwise it would be a minor version change.

by mythz 2y ago

jitl 2y ago

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.

mythz 2y ago
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.
- jitl 2y ago
  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.
  - mythz 2y ago
    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.
    - Aeolun 2y ago
      I find it really hard to not immediately be reminded of this: https://xkcd.com/1172/ https://xkcd.com/1172/
      - mythz 2y ago
        We only use npm dependencies and bloated node_modules folders [1] if we absolutely have to and for our non node.js Apps we explicitly don't. [1] https://www.reddit.com/r/ProgrammerHumor/comments/6s0wov/heaviest_objects_in_the_universe/ https://www.reddit.com/r/ProgrammerHumor/comments/6s0wov/hea...
        preisschild 2y ago
        But why not though 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.
        mythz 2y ago
        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.
        jitl 2y ago
- nejsjsjsbsb 2y ago
  Shove an @ version in it
  - mythz 2y ago
    Yep `npx tailwindcss@v3` is the solution we ended up with. Just had to change this in all our Apps and project templates.
    - nejsjsjsbsb 2y ago
      I wish @-less wasn't be allowed. Like you can do @latest but then human confirm is needed. That way you don't get this problem in scripts.
      - jakubmazanec 2y ago
        > then human confirm is needed "Suppress this prompt with the -y or --yes option" [1] [1] https://docs.npmjs.com/cli/v11/commands/npx https://docs.npmjs.com/cli/v11/commands/npx
- GrzegorzWidla 2y ago
  So why not npx tailwindcss@^3.0.0 (or whatever version was there when you started)?

aembleton 2y ago

> Given its massive install base, surprised they wouldn't maintain backward compatibility with v3 and have an explicit opt-in upgrade path to v4. Given it's a major version change, I'd expect it to create breaking changes, otherwise it would be a minor version change.