tailwindcss/packages/@tailwindcss-vite/package.json

43 lines
1,013 B
JSON
Raw Permalink Normal View History

2024-03-05 14:23:26 +01:00
{
"name": "@tailwindcss/vite",
2026-08-31 13:17:41 +02:00
"version": "4.3.4",
2024-03-05 14:23:26 +01:00
"description": "A utility-first CSS framework for rapidly building custom user interfaces.",
"license": "MIT",
"repository": {
"type": "git",
"url": "https://github.com/tailwindlabs/tailwindcss.git",
"directory": "packages/@tailwindcss-vite"
},
2024-03-05 14:23:26 +01:00
"bugs": "https://github.com/tailwindlabs/tailwindcss/issues",
"homepage": "https://tailwindcss.com",
"scripts": {
Add `@source` support (#14078) This PR is an umbrella PR where we will add support for the new `@source` directive. This will allow you to add explicit content glob patterns if you want to look for Tailwind classes in other files that are not automatically detected yet. Right now this is an addition to the existing auto content detection that is automatically enabled in the `@tailwindcss/postcss` and `@tailwindcss/cli` packages. The `@tailwindcss/vite` package doesn't use the auto content detection, but uses the module graph instead. From an API perspective there is not a lot going on. There are only a few things that you have to know when using the `@source` directive, and you probably already know the rules: 1. You can use multiple `@source` directives if you want. 2. The `@source` accepts a glob pattern so that you can match multiple files at once 3. The pattern is relative to the current file you are in 4. The pattern includes all files it is matching, even git ignored files 1. The motivation for this is so that you can explicitly point to a `node_modules` folder if you want to look at `node_modules` for whatever reason. 6. Right now we don't support negative globs (starting with a `!`) yet, that will be available in the near future. Usage example: ```css /* ./src/input.css */ @import "tailwindcss"; @source "../laravel/resources/views/**/*.blade.php"; @source "../../packages/monorepo-package/**/*.js"; ``` It looks like the PR introduced a lot of changes, but this is a side effect of all the other plumbing work we had to do to make this work. For example: 1. We added dedicated integration tests that run on Linux and Windows in CI (just to make sure that all the `path` logic is correct) 2. We Have to make sure that the glob patterns are always correct even if you are using `@import` in your CSS and use `@source` in an imported file. This is because we receive the flattened CSS contents where all `@import`s are inlined. 3. We have to make sure that we also listen for changes in the files that match any of these patterns and trigger a rebuild. PRs: - [x] https://github.com/tailwindlabs/tailwindcss/pull/14063 - [x] https://github.com/tailwindlabs/tailwindcss/pull/14085 - [x] https://github.com/tailwindlabs/tailwindcss/pull/14079 - [x] https://github.com/tailwindlabs/tailwindcss/pull/14067 - [x] https://github.com/tailwindlabs/tailwindcss/pull/14076 - [x] https://github.com/tailwindlabs/tailwindcss/pull/14080 - [x] https://github.com/tailwindlabs/tailwindcss/pull/14127 - [x] https://github.com/tailwindlabs/tailwindcss/pull/14135 Once all the PRs are merged, then this umbrella PR can be merged. > [!IMPORTANT] > Make sure to merge this without rebasing such that each individual PR ends up on the main branch. --------- Co-authored-by: Philipp Spiess <hello@philippspiess.com> Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2024-08-07 16:38:44 +02:00
"build": "tsup-node",
2024-03-05 14:23:26 +01:00
"dev": "pnpm run build -- --watch"
},
"files": [
"dist/"
],
"publishConfig": {
"provenance": true,
"access": "public"
},
2024-03-05 14:23:26 +01:00
"exports": {
".": {
"types": "./dist/index.d.mts",
"default": "./dist/index.mjs"
2024-03-05 14:23:26 +01:00
}
},
"dependencies": {
"@tailwindcss/node": "workspace:*",
"@tailwindcss/oxide": "workspace:*",
Ensure clients pin the `tailwindcss` version (#15011) We noticed that in the current alpha 34 release, the `package.json` file of the `@tailwindcss/node` package only defines `tailwindcss` as a dev dependency. This makes it very easy for version mismatches to happen when a v3 version (or an earlier v4 alpha for that matter) was installed in the same project: ```json { "name": "@tailwindcss/node", "version": "4.0.0-alpha.34", "description": "A utility-first CSS framework for rapidly building custom user interfaces.", "license": "MIT", "repository": { "type": "git", "url": "https://github.com/tailwindlabs/tailwindcss.git", "directory": "packages/@tailwindcss-node" }, "bugs": "https://github.com/tailwindlabs/tailwindcss/issues", "homepage": "https://tailwindcss.com", "files": [ "dist/" ], "publishConfig": { "provenance": true, "access": "public" }, "exports": { ".": { "types": "./dist/index.d.ts", "import": "./dist/index.mjs", "require": "./dist/index.js" }, "./require-cache": { "types": "./dist/require-cache.d.ts", "default": "./dist/require-cache.js" }, "./esm-cache-loader": { "types": "./dist/esm-cache.loader.d.mts", "default": "./dist/esm-cache.loader.mjs" } }, "devDependencies": { "tailwindcss": "4.0.0-alpha.34" }, "dependencies": { "enhanced-resolve": "^5.17.1", "jiti": "^2.0.0-beta.3" }, "scripts": { "build": "tsup-node", "dev": "pnpm run build -- --watch" } } ``` Furthermore, we were trying to fix issues where our integration test setup could not install `tailwindcss@3` because of how we did pnpm overrides. This PR fixes this by: - Ensuring every client that calls into `tailwindcss` core marks it as a version-pinned dependency. You are still required to install `tailwindcss` in your project along side a client (e.g. `@tailwindcss/vite`) but we now only use your installed version for importing the respective `.css` files. For the core logic, we are now requiring each package to use `tailwindcss` at the same version. This should help resolve issues like https://github.com/tailwindlabs/tailwindcss/discussions/14652 - We tried to eliminate the dependency on `tailwindcss` from the `@tailwindcss/upgrade` package. Unfortunately this is not possible to do right now because we need to load the CSS files from v4 to create the right environment. In a future version we could bundle the required CSS files with `@tailwidncss/upgrade` but it doesn't seem necessary for now. - We then changed our integration test overrides to only override the `tailwindcss` package that are dependencies of the known list of packages that we have `tailwindcss` dependencies on: `@tailwindcss/node` and `@tailwindcss/upgrade`. This ensures that we can install v3 of `tailwindcss` in the integration tests and it will work. Something we want to do for some upgrade tests. # Test plan Integration work again. Furthermore we added a quick setup with the CLI using the local tarballs and ensured it works: ```bash pnpm init pnpm install ../../tailwindcss/dist/tailwindcss-cli.tgz pnpm install ../../tailwindcss/dist/tailwindcss.tgz echo '@import "tailwindcss";' > index.css echo '<div class="underline"></div>' > index.html pnpm tailwindcss -i index.css -o out.css cat out.css ```
2024-11-15 17:18:48 +01:00
"tailwindcss": "workspace:*"
2024-03-05 14:23:26 +01:00
},
"devDependencies": {
"@types/node": "catalog:",
Rework Vite plugin to support lightningcss pre processor and fast rebuilds (#14269) Fixes #14205 Fixes #14106 This PR reworks the Vite extension in order to supprt `lightningcss` as the pre-processor, enable faster rebuilds, and adds support for `vite build --watch` mode. To make this change possible, we've done two major changes to the extension that have caused the other changes. ## 1. Tailwind CSS is a preprocessor We now run all of our modifications in `enforce: 'pre'`. This means that Tailwind CSS now gets the untransformed CSS files rather than the one already going through postcss or lightningcss. We do this because Tailwind CSS _is_ a preprocessor at the same level as those tools and we do sometimes use the language in ways that [creates problems when it's the input for other bundlers](https://github.com/tailwindlabs/tailwindcss/pull/14269). The correct solution here is to make Tailwind not depend on any other transformations. The main reason we were not using the `enforce: 'pre'` phase in Vite before was becuase we relied on the `@import` flattening of postcss so we now have to do this manually. `@import` flattening is now a concern that every Tailwind V4 client has to deal with so this might actually be something we want to inline into tailwindcss in the future. ## 2. A Vite config can have multiple Tailwind roots This is something that we have not made very explicit in the previous iteration of the Vite plugin but we have to support multiple Tailwind roots in a single Vite workspace. A Tailwind root is a CSS file that is used to configure Tailwind. Technically, any CSS file can be the input for `tailwindcss` but you have to add certain rules (e.g. `@import "tailwindcss";`) to make the compiler do something. A workspace can have multiple of these rules (e.g. by having different Tailwind configures for different sub-pages). With the addition of [support for `@source` rules](https://github.com/tailwindlabs/tailwindcss/pull/14078) and [JS config files](https://github.com/tailwindlabs/tailwindcss/pull/14239), Tailwind roots become more complex and can have a custom list of _dependencies_ (that is other JavaScript modules the compiler includes as part of these new rules). In order to _only rebuild the roots we need to_, we have to make this separation very clear. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-09-04 10:09:24 +02:00
"vite": "catalog:"
},
"peerDependencies": {
"vite": "^5.2.0 || ^6 || ^7 || ^8"
2024-03-05 14:23:26 +01:00
}
}