wrapper/tailwindcss
1
0
Fork 0
Code Issues Pull requests Projects Releases 1 Packages Wiki Activity Actions
tailwindcss/packages/@tailwindcss-vite/package.json

45 lines
1.1 KiB
JSON
Raw Permalink Normal View History

introduce v4 codebase
2024-03-05 14:23:26 +01:00
{
"name": "@tailwindcss/vite",
Prepare for v4.0.0-alpha.18 release (#14057) Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
2024-07-25 10:19:13 -04:00
"version": "4.0.0-alpha.18",
introduce v4 codebase
2024-03-05 14:23:26 +01:00
"description": "A utility-first CSS framework for rapidly building custom user interfaces.",
"license": "MIT",
[v4] Add provenance to all published packages (#13160) * Add provenance to all packages Based on #13097 by @saibotk Add [provenance](https://docs.npmjs.com/generating-provenance-statements) for all published packages. --- Co-authored-by: saibotk <git@saibotk.de> * Document reason for id-token permission * Update changelog
2024-03-08 15:30:13 -05:00
"repository": {
"type": "git",
Correct repository fields in package.json files (#13416)
2024-03-31 21:20:53 +02:00
"url": "https://github.com/tailwindlabs/tailwindcss.git",
[v4] Add provenance to all published packages (#13160) * Add provenance to all packages Based on #13097 by @saibotk Add [provenance](https://docs.npmjs.com/generating-provenance-statements) for all published packages. --- Co-authored-by: saibotk <git@saibotk.de> * Document reason for id-token permission * Update changelog
2024-03-08 15:30:13 -05:00
"directory": "packages/@tailwindcss-vite"
},
introduce v4 codebase
2024-03-05 14:23:26 +01:00
"bugs": "https://github.com/tailwindlabs/tailwindcss/issues",
"homepage": "https://tailwindcss.com",
"scripts": {
Add PostCSS plugin to fix relative `@content` and `@plugin` paths in `@import`ed files (#14063) We noticed an issue that happened when handling relative file imports in the `@plugin` and the upcoming `@content` APIs. The problem arises from relative files that are inside `@import`ed stylesheets. Take, for example, the following folder structure: ```css /* src/index.css */ @import "./dir/index.css"; ``` ```css /* src/dir/index.css */ @plugin "../../plugin.ts"; ``` It's expected that the path is relative to the CSS file that defined it. However, right now, we use [`postcss-import`](https://github.com/postcss/postcss-import) to flatten the CSS file before running the tailwind build step. This causes these custom-properties to be inlined in a flat file which removes the information of which file is being referred: ```css /* src/flat.css */ @plugin "../../plugin.ts"; /* <- This is now pointing to the wrong file */ ``` There are generally two approaches that we can do to solve this: 1. **Handle `@import` flattening inside tailwindcss:** While generally this would give us more freedom and less dependencies, this would require some work to get all edge cases right. We need to support layers/conditional imports and also handle all relative urls for properties like `background-image`. 2. **Rewrite relative paths as a separate postcss visitor:** The approach this PR takes is instead to implement a custom postcss plugin that uses the AST to rewrite relative references inside `@plugin` and `@content`. This has the benefit of requiring little changes to our existing APIs. The rule is only enabled for relative references inside `@plugin` and `@content`, so the surface of this rule is very small. We can use this plugin inside all three current clients: - `@tailwindcss/postcss` obviously already uses postcss - `@tailwindcss/cli` also uses postcss to handle `@import` flattening - `@tailwindcss/vite` allows us to add custom postcss rules via the CSS pipeline. There are a few cases that we handle with care (e.g. in vite you can pass a string to the postcss config which is supposed to load the config from a file). To validate the changes, we have added both a list of unit test cases to the plugin itself as well as verified that all three clients are working as expected: - `@tailwindcss/postcss` now has an explicit test for this behavior - `@tailwindcss/cli` and `@tailwindcss/vite` were manually tested by updating the vite playground. The CLI was run with `--cwd playgrounds/vite/ -i ./src/app.css -o foo.css`: <img width="531" alt="Screenshot 2024-07-29 at 11 35 59" src="https://github.com/user-attachments/assets/78f0acdc-a46c-4c6c-917a-2916417b1001">
2024-07-29 17:57:50 +02:00
"build": "tsup-node",
introduce v4 codebase
2024-03-05 14:23:26 +01:00
"dev": "pnpm run build -- --watch"
},
"files": [
"dist/"
],
[v4] Add provenance to all published packages (#13160) * Add provenance to all packages Based on #13097 by @saibotk Add [provenance](https://docs.npmjs.com/generating-provenance-statements) for all published packages. --- Co-authored-by: saibotk <git@saibotk.de> * Document reason for id-token permission * Update changelog
2024-03-08 15:30:13 -05:00
"publishConfig": {
add `"access": "public"` to `publishConfig` (#13164)
2024-03-08 22:04:05 +01:00
"provenance": true,
"access": "public"
[v4] Add provenance to all published packages (#13160) * Add provenance to all packages Based on #13097 by @saibotk Add [provenance](https://docs.npmjs.com/generating-provenance-statements) for all published packages. --- Co-authored-by: saibotk <git@saibotk.de> * Document reason for id-token permission * Update changelog
2024-03-08 15:30:13 -05:00
},
introduce v4 codebase
2024-03-05 14:23:26 +01:00
"exports": {
".": {
"types": "./dist/index.d.mts",
"import": "./dist/index.mjs"
}
},
"dependencies": {
"@tailwindcss/oxide": "workspace:^",
Bump dependencies (#13741) * bump dependencies * update tests to reflect Lightning CSS change
2024-05-25 14:43:59 +02:00
"lightningcss": "^1.25.1",
Add PostCSS plugin to fix relative `@content` and `@plugin` paths in `@import`ed files (#14063) We noticed an issue that happened when handling relative file imports in the `@plugin` and the upcoming `@content` APIs. The problem arises from relative files that are inside `@import`ed stylesheets. Take, for example, the following folder structure: ```css /* src/index.css */ @import "./dir/index.css"; ``` ```css /* src/dir/index.css */ @plugin "../../plugin.ts"; ``` It's expected that the path is relative to the CSS file that defined it. However, right now, we use [`postcss-import`](https://github.com/postcss/postcss-import) to flatten the CSS file before running the tailwind build step. This causes these custom-properties to be inlined in a flat file which removes the information of which file is being referred: ```css /* src/flat.css */ @plugin "../../plugin.ts"; /* <- This is now pointing to the wrong file */ ``` There are generally two approaches that we can do to solve this: 1. **Handle `@import` flattening inside tailwindcss:** While generally this would give us more freedom and less dependencies, this would require some work to get all edge cases right. We need to support layers/conditional imports and also handle all relative urls for properties like `background-image`. 2. **Rewrite relative paths as a separate postcss visitor:** The approach this PR takes is instead to implement a custom postcss plugin that uses the AST to rewrite relative references inside `@plugin` and `@content`. This has the benefit of requiring little changes to our existing APIs. The rule is only enabled for relative references inside `@plugin` and `@content`, so the surface of this rule is very small. We can use this plugin inside all three current clients: - `@tailwindcss/postcss` obviously already uses postcss - `@tailwindcss/cli` also uses postcss to handle `@import` flattening - `@tailwindcss/vite` allows us to add custom postcss rules via the CSS pipeline. There are a few cases that we handle with care (e.g. in vite you can pass a string to the postcss config which is supposed to load the config from a file). To validate the changes, we have added both a list of unit test cases to the plugin itself as well as verified that all three clients are working as expected: - `@tailwindcss/postcss` now has an explicit test for this behavior - `@tailwindcss/cli` and `@tailwindcss/vite` were manually tested by updating the vite playground. The CLI was run with `--cwd playgrounds/vite/ -i ./src/app.css -o foo.css`: <img width="531" alt="Screenshot 2024-07-29 at 11 35 59" src="https://github.com/user-attachments/assets/78f0acdc-a46c-4c6c-917a-2916417b1001">
2024-07-29 17:57:50 +02:00
"postcss-load-config": "^6.0.1",
introduce v4 codebase
2024-03-05 14:23:26 +01:00
"tailwindcss": "workspace:^"
},
"devDependencies": {
Bump dependencies (#13738) * run `pnpm update --recursive` * update tests to reflect lightningcss bump It looks like it's mainly (re-)ordering properties. Not 100% sure why though.
2024-05-24 15:07:44 +02:00
"@types/node": "^20.12.12",
Add PostCSS plugin to fix relative `@content` and `@plugin` paths in `@import`ed files (#14063) We noticed an issue that happened when handling relative file imports in the `@plugin` and the upcoming `@content` APIs. The problem arises from relative files that are inside `@import`ed stylesheets. Take, for example, the following folder structure: ```css /* src/index.css */ @import "./dir/index.css"; ``` ```css /* src/dir/index.css */ @plugin "../../plugin.ts"; ``` It's expected that the path is relative to the CSS file that defined it. However, right now, we use [`postcss-import`](https://github.com/postcss/postcss-import) to flatten the CSS file before running the tailwind build step. This causes these custom-properties to be inlined in a flat file which removes the information of which file is being referred: ```css /* src/flat.css */ @plugin "../../plugin.ts"; /* <- This is now pointing to the wrong file */ ``` There are generally two approaches that we can do to solve this: 1. **Handle `@import` flattening inside tailwindcss:** While generally this would give us more freedom and less dependencies, this would require some work to get all edge cases right. We need to support layers/conditional imports and also handle all relative urls for properties like `background-image`. 2. **Rewrite relative paths as a separate postcss visitor:** The approach this PR takes is instead to implement a custom postcss plugin that uses the AST to rewrite relative references inside `@plugin` and `@content`. This has the benefit of requiring little changes to our existing APIs. The rule is only enabled for relative references inside `@plugin` and `@content`, so the surface of this rule is very small. We can use this plugin inside all three current clients: - `@tailwindcss/postcss` obviously already uses postcss - `@tailwindcss/cli` also uses postcss to handle `@import` flattening - `@tailwindcss/vite` allows us to add custom postcss rules via the CSS pipeline. There are a few cases that we handle with care (e.g. in vite you can pass a string to the postcss config which is supposed to load the config from a file). To validate the changes, we have added both a list of unit test cases to the plugin itself as well as verified that all three clients are working as expected: - `@tailwindcss/postcss` now has an explicit test for this behavior - `@tailwindcss/cli` and `@tailwindcss/vite` were manually tested by updating the vite playground. The CLI was run with `--cwd playgrounds/vite/ -i ./src/app.css -o foo.css`: <img width="531" alt="Screenshot 2024-07-29 at 11 35 59" src="https://github.com/user-attachments/assets/78f0acdc-a46c-4c6c-917a-2916417b1001">
2024-07-29 17:57:50 +02:00
"internal-postcss-fix-relative-paths": "workspace:^",
Bump dependencies (#13738) * run `pnpm update --recursive` * update tests to reflect lightningcss bump It looks like it's mainly (re-)ordering properties. Not 100% sure why though.
2024-05-24 15:07:44 +02:00
"vite": "^5.2.11"
Process Tailwind output with Vite CSS plugins (#13218) Transform Tailwind-generated CSS with Vite CSS plugins. vite:css does useful things like transforming url() paths and inlining images. vite:css-post generates bundle hashes. Before this change, the CSS bundle hash wasn't changing when the generated CSS changed. Also adds Vite 5.2 peerDependancy. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me>
2024-03-22 14:57:44 -04:00
},
"peerDependencies": {
"vite": "^5.2.0"
introduce v4 codebase
2024-03-05 14:23:26 +01:00
}
}
Reference in a new issue Copy permalink