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

56 lines
1.8 KiB
JSON
Raw Normal View History

Add standalone CLI (#14270) This PR adds a new standalone client: A single-binary file that you can use to run Tailwind v4 without having a node setup. To make this work we use Bun's single-binary build which can properly package up native modules and the bun runtime for us so we do not have to rely on any expand-into-tmp-folder-at-runtime workarounds. When running locally, `pnpm build` will now standalone artifacts inside `packages/@tailwindcss-standalone/dist`. Note that since we do not build Oxide for other environments in the local setup, you won't be able to use the standalone artifacts for other platforms in local dev mode. Unfortunately Bun does not have support for Windows ARM builds yet but we found that using the `bun-baseline` runtime for Windows x64 would make the builds work fine in ARM emulation mode: ![Screenshot windows](https://github.com/user-attachments/assets/5b39387f-ec50-4757-9469-19b98e43162d) Some Bun related issues we faced and worked around: - We found that the regular Windows x64 build of `bun` does not run on Windows ARM via emulation. Instead, we have to use the `bun-baseline` builds which emulate correctly. - When we tried to bundle artifacts with [embed directories](https://bun.sh/docs/bundler/executables#embed-directories), node binary dependencies were no longer resolved correctly even though they would still be bundled and accessible within the [`embeddedFiles` list](https://bun.sh/docs/bundler/executables#listing-embedded-files). We worked around this by using the `import * as from ... with { type: "file" };` and patching the resolver we use in our CLI. - If you have an import to a module that is used as a regular import _and_ a `with { type: "file" }`, it will either return the module in both cases _or_ the file path when we would expect only the `with { type: "file" }` import to return the path. We do read the Tailwind CSS version via the file system and `require.resolve()` in the CLI and via `import * from './package.json'` in core and had to work around this by patching the version resolution in our CLI. ```ts import packageJson from "./package.json" import packageJsonPath from "./package.json" with {type: "file"} // We do not expect these to be equal packageJson === packageJsonPath ``` - We can not customize the app icon used for Windows `.exe` builds without decompiling the binary. For now we will leave the default but one workaround is to [use tools like ResourceHacker](https://github.com/tailwindlabs/tailwindcss/pull/14270/commits/698d9c4bd182391adb4b236f19a539aff13f78f9) to decompile the binary first. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-09-02 15:23:46 +02:00
{
"name": "@tailwindcss/standalone",
4.3.3 (#20334)
2026-07-16 13:21:50 +02:00
"version": "4.3.3",
Add GitHub release workflow (#14346) Co-authored-by: Philipp Spiess <hello@philippspiess.com>
2024-09-05 09:45:29 -04:00
"private": true,
Add standalone CLI (#14270) This PR adds a new standalone client: A single-binary file that you can use to run Tailwind v4 without having a node setup. To make this work we use Bun's single-binary build which can properly package up native modules and the bun runtime for us so we do not have to rely on any expand-into-tmp-folder-at-runtime workarounds. When running locally, `pnpm build` will now standalone artifacts inside `packages/@tailwindcss-standalone/dist`. Note that since we do not build Oxide for other environments in the local setup, you won't be able to use the standalone artifacts for other platforms in local dev mode. Unfortunately Bun does not have support for Windows ARM builds yet but we found that using the `bun-baseline` runtime for Windows x64 would make the builds work fine in ARM emulation mode: ![Screenshot windows](https://github.com/user-attachments/assets/5b39387f-ec50-4757-9469-19b98e43162d) Some Bun related issues we faced and worked around: - We found that the regular Windows x64 build of `bun` does not run on Windows ARM via emulation. Instead, we have to use the `bun-baseline` builds which emulate correctly. - When we tried to bundle artifacts with [embed directories](https://bun.sh/docs/bundler/executables#embed-directories), node binary dependencies were no longer resolved correctly even though they would still be bundled and accessible within the [`embeddedFiles` list](https://bun.sh/docs/bundler/executables#listing-embedded-files). We worked around this by using the `import * as from ... with { type: "file" };` and patching the resolver we use in our CLI. - If you have an import to a module that is used as a regular import _and_ a `with { type: "file" }`, it will either return the module in both cases _or_ the file path when we would expect only the `with { type: "file" }` import to return the path. We do read the Tailwind CSS version via the file system and `require.resolve()` in the CLI and via `import * from './package.json'` in core and had to work around this by patching the version resolution in our CLI. ```ts import packageJson from "./package.json" import packageJsonPath from "./package.json" with {type: "file"} // We do not expect these to be equal packageJson === packageJsonPath ``` - We can not customize the app icon used for Windows `.exe` builds without decompiling the binary. For now we will leave the default but one workaround is to [use tools like ResourceHacker](https://github.com/tailwindlabs/tailwindcss/pull/14270/commits/698d9c4bd182391adb4b236f19a539aff13f78f9) to decompile the binary first. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-09-02 15:23:46 +02:00
"description": "Standalone CLI for Tailwind CSS",
"license": "MIT",
"repository": {
"type": "git",
"url": "https://github.com/tailwindlabs/tailwindcss.git",
"directory": "packages/@tailwindcss-standalone"
},
"bugs": "https://github.com/tailwindlabs/tailwindcss/issues",
"homepage": "https://tailwindcss.com",
"scripts": {
"lint": "tsc --noEmit",
"build": "bun ./scripts/build.ts"
},
"bin": {
"tailwindcss": "./dist/index.mjs"
},
"exports": {
"./package.json": "./package.json"
},
"files": [
"dist"
],
"dependencies": {
Bundle core plugins with the standalone build (#15028) Closes #15012 We do not have replacements for these plugins _just yet_. In order to increase compatibility with setups that rely on some of these legacy plugins, this PR bundles `@tailwindcss/forms`, `@tailwindcss/typography`, and `@tailwindcss/aspect-ratio` (after https://github.com/tailwindlabs/tailwindcss/pull/15029) with the standalone build now. In comparison to v3, this omits the `@tailwindcss/container-queries` plugin since is not a first-party feature of Tailwind CSS v4. ## Test Plan Added an integration test. I also tested this by running the standalone binary in a temporary folder with as simple input css: ```css @import "tailwindcss"; @plugin "@tailwindcss/typography"; ```
2024-11-19 16:19:08 +01:00
"@tailwindcss/aspect-ratio": "^0.4.2",
Pin exact versions of `tailwindcss` and `@tailwindcss/*` (#16623) This PR fixes an issue where installing a specific version of `@tailwindcss/postcss` and `tailwindcss` could still result in a version mismatch. This is because we were relying on `^4.0.6` for example instead of `4.0.6`. This PR now pins all these versions to prevent this: ``` ❯ pnpm why tailwindcss devDependencies: @tailwindcss/postcss 4.0.5 ├─┬ @tailwindcss/node 4.0.6 │ └── tailwindcss 4.0.6 └── tailwindcss 4.0.5 ```
2025-02-18 11:44:12 +01:00
"@tailwindcss/cli": "workspace:*",
Update @tailwindcss/forms 0.5.10 → 0.5.11 (minor) (#19490) Here is everything you need to know about this update. Please take a good look at what changed and the test results before merging this pull request. ### What changed? #### ✳️ @​tailwindcss/forms (0.5.10 → 0.5.11) · [Repo](https://github.com/tailwindlabs/tailwindcss-forms) · [Changelog](https://github.com/tailwindlabs/tailwindcss-forms/blob/main/CHANGELOG.md) <details> <summary>Release Notes</summary> <h4><a href="https://github.com/tailwindlabs/tailwindcss-forms/releases/tag/v0.5.11">0.5.11</a></h4> <blockquote><h3 dir="auto">Fixed</h3> <ul dir="auto"> <li>Limit attribute rules to input and select elements (<a href="https://bounce.depfu.com/github.com/tailwindlabs/tailwindcss-forms/pull/159">#159</a>)</li> </ul></blockquote> <p><em>Does any of this look wrong? <a href="https://depfu.com/packages/npm/@tailwindcss%2Fforms/feedback">Please let us know.</a></em></p> </details> <details> <summary>Commits</summary> <p><a href="https://github.com/tailwindlabs/tailwindcss-forms/compare/071d1c03fdba6a1cab3ee7893ac51279b69fcb75...e1b609d57954eb0036c4c2e7ae9c9c2ba558146b">See the full diff on Github</a>. The new version differs by 3 commits:</p> <ul> <li><a href="https://github.com/tailwindlabs/tailwindcss-forms/commit/e1b609d57954eb0036c4c2e7ae9c9c2ba558146b"><code>0.5.11</code></a></li> <li><a href="https://github.com/tailwindlabs/tailwindcss-forms/commit/67ff8ea3dc0093d5c9f4c45cc8413e8c5bc082d6"><code>Limit attribute rules to input and select elements (#159)</code></a></li> <li><a href="https://github.com/tailwindlabs/tailwindcss-forms/commit/fc3f7e6bce06a1985d445c53e90c3c7fac0e1d18"><code>docs: update installation guide to add tailwind css v4 instructions while keeping v3 details (#180)</code></a></li> </ul> </details> --- ![Depfu Status](https://depfu.com/badges/edd6acd35d74c8d41cbb540c30442adf/stats.svg) [Depfu](https://depfu.com) will automatically keep this PR conflict-free, as long as you don't add any commits to this branch yourself. You can also trigger a rebase manually by commenting with `@depfu rebase`. <details><summary>All Depfu comment commands</summary> <blockquote><dl> <dt>@​depfu rebase</dt><dd>Rebases against your default branch and redoes this update</dd> <dt>@​depfu recreate</dt><dd>Recreates this PR, overwriting any edits that you've made to it</dd> <dt>@​depfu merge</dt><dd>Merges this PR once your tests are passing and conflicts are resolved</dd> <dt>@​depfu cancel merge</dt><dd>Cancels automatic merging of this PR</dd> <dt>@​depfu close</dt><dd>Closes this PR and deletes the branch</dd> <dt>@​depfu reopen</dt><dd>Restores the branch and reopens this PR (if it's closed)</dd> <dt>@​depfu pause</dt><dd>Ignores all future updates for this dependency and closes this PR</dd> <dt>@​depfu pause [minor|major]</dt><dd>Ignores all future minor/major updates for this dependency and closes this PR</dd> <dt>@​depfu resume</dt><dd>Future versions of this dependency will create PRs again (leaves this PR as is)</dd> </dl></blockquote> </details> Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com>
2025-12-24 17:20:21 -05:00
"@tailwindcss/forms": "^0.5.11",
Update all pnpm dependencies (2026-06-15) (#20241) This is your weekly update of **all** pnpm dependencies. Please take a good look at what changed and the test results before merging this pull request. ### What changed? ✳️ @emnapi/core (1.10.0 → 1.11.1, minor) · [Repo](https://github.com/toyobayashi/emnapi) · [Release](https://github.com/toyobayashi/emnapi/releases/tag/v1.11.1) · [Diff](https://github.com/toyobayashi/emnapi/compare/ba84999164c8d9ee10e57f72bb6fa5fa0b192b54...6c3668c9afbfa96cf030a74705f1ff7868d332bd) ✳️ @emnapi/runtime (1.10.0 → 1.11.1, minor) · [Repo](https://github.com/toyobayashi/emnapi) · [Release](https://github.com/toyobayashi/emnapi/releases/tag/v1.11.1) · [Diff](https://github.com/toyobayashi/emnapi/compare/ba84999164c8d9ee10e57f72bb6fa5fa0b192b54...6c3668c9afbfa96cf030a74705f1ff7868d332bd) ✳️ @tailwindcss/typography (0.5.19 → 0.5.20, minor) · [Repo](https://github.com/tailwindlabs/tailwindcss-typography) · [Changelog](https://github.com/tailwindlabs/tailwindcss-typography/blob/main/CHANGELOG.md) · [Release](https://github.com/tailwindlabs/tailwindcss-typography/releases/tag/v0.5.20) · [Diff](https://github.com/tailwindlabs/tailwindcss-typography/compare/e002ab89ad8f4202638249c1c300c0cf0b3739c5...e3714a3fe55551ce9d51eec4721183ed6b1d5cd1) ✳️ @emnapi/wasi-threads (1.2.1 → 1.2.2, patch) · [Repo](https://github.com/toyobayashi/emnapi) --- ![Depfu Status](https://depfu.com/badges/edd6acd35d74c8d41cbb540c30442adf/stats.svg) [Depfu](https://depfu.com) will only send you the next scheduled PR once you merge or close this one. <details><summary>All Depfu comment commands</summary> <blockquote><dl> <dt>@​depfu refresh</dt><dd>Rebases against your default branch and redoes this update</dd> <dt>@​depfu recreate</dt><dd>Recreates this PR, overwriting any edits that you've made to it</dd> <dt>@​depfu merge</dt><dd>Merges this PR once your tests are passing and conflicts are resolved</dd> <dt>@​depfu cancel merge</dt><dd>Cancels automatic merging of this PR</dd> <dt>@​depfu close</dt><dd>Closes this PR and deletes the branch</dd> <dt>@​depfu reopen</dt><dd>Restores the branch and reopens this PR (if it's closed)</dd> </dl></blockquote> </details> --------- Co-authored-by: depfu[bot] <23717796+depfu[bot]@users.noreply.github.com> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2026-06-15 13:13:32 +00:00
"@tailwindcss/typography": "^0.5.20",
Add standalone CLI (#14270) This PR adds a new standalone client: A single-binary file that you can use to run Tailwind v4 without having a node setup. To make this work we use Bun's single-binary build which can properly package up native modules and the bun runtime for us so we do not have to rely on any expand-into-tmp-folder-at-runtime workarounds. When running locally, `pnpm build` will now standalone artifacts inside `packages/@tailwindcss-standalone/dist`. Note that since we do not build Oxide for other environments in the local setup, you won't be able to use the standalone artifacts for other platforms in local dev mode. Unfortunately Bun does not have support for Windows ARM builds yet but we found that using the `bun-baseline` runtime for Windows x64 would make the builds work fine in ARM emulation mode: ![Screenshot windows](https://github.com/user-attachments/assets/5b39387f-ec50-4757-9469-19b98e43162d) Some Bun related issues we faced and worked around: - We found that the regular Windows x64 build of `bun` does not run on Windows ARM via emulation. Instead, we have to use the `bun-baseline` builds which emulate correctly. - When we tried to bundle artifacts with [embed directories](https://bun.sh/docs/bundler/executables#embed-directories), node binary dependencies were no longer resolved correctly even though they would still be bundled and accessible within the [`embeddedFiles` list](https://bun.sh/docs/bundler/executables#listing-embedded-files). We worked around this by using the `import * as from ... with { type: "file" };` and patching the resolver we use in our CLI. - If you have an import to a module that is used as a regular import _and_ a `with { type: "file" }`, it will either return the module in both cases _or_ the file path when we would expect only the `with { type: "file" }` import to return the path. We do read the Tailwind CSS version via the file system and `require.resolve()` in the CLI and via `import * from './package.json'` in core and had to work around this by patching the version resolution in our CLI. ```ts import packageJson from "./package.json" import packageJsonPath from "./package.json" with {type: "file"} // We do not expect these to be equal packageJson === packageJsonPath ``` - We can not customize the app icon used for Windows `.exe` builds without decompiling the binary. For now we will leave the default but one workaround is to [use tools like ResourceHacker](https://github.com/tailwindlabs/tailwindcss/pull/14270/commits/698d9c4bd182391adb4b236f19a539aff13f78f9) to decompile the binary first. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-09-02 15:23:46 +02:00
"detect-libc": "1.0.3",
Bump dependencies (#20095) This PR bumps some of our dependencies, common dependencies were moved to pnpm's `catalog` feature. Closes #20092 Closes #20085 Closes #20075 Closes #20066 Closes #20062 ## Test plan - All tests still pass - Each dependency was published some time ago. Webpack has an even newer version that was published <15min ago. Will update that one later. [ci-all]
2026-05-21 17:58:55 +02:00
"enhanced-resolve": "catalog:",
Pin exact versions of `tailwindcss` and `@tailwindcss/*` (#16623) This PR fixes an issue where installing a specific version of `@tailwindcss/postcss` and `tailwindcss` could still result in a version mismatch. This is because we were relying on `^4.0.6` for example instead of `4.0.6`. This PR now pins all these versions to prevent this: ``` ❯ pnpm why tailwindcss devDependencies: @tailwindcss/postcss 4.0.5 ├─┬ @tailwindcss/node 4.0.6 │ └── tailwindcss 4.0.6 └── tailwindcss 4.0.5 ```
2025-02-18 11:44:12 +01:00
"tailwindcss": "workspace:*"
Add standalone CLI (#14270) This PR adds a new standalone client: A single-binary file that you can use to run Tailwind v4 without having a node setup. To make this work we use Bun's single-binary build which can properly package up native modules and the bun runtime for us so we do not have to rely on any expand-into-tmp-folder-at-runtime workarounds. When running locally, `pnpm build` will now standalone artifacts inside `packages/@tailwindcss-standalone/dist`. Note that since we do not build Oxide for other environments in the local setup, you won't be able to use the standalone artifacts for other platforms in local dev mode. Unfortunately Bun does not have support for Windows ARM builds yet but we found that using the `bun-baseline` runtime for Windows x64 would make the builds work fine in ARM emulation mode: ![Screenshot windows](https://github.com/user-attachments/assets/5b39387f-ec50-4757-9469-19b98e43162d) Some Bun related issues we faced and worked around: - We found that the regular Windows x64 build of `bun` does not run on Windows ARM via emulation. Instead, we have to use the `bun-baseline` builds which emulate correctly. - When we tried to bundle artifacts with [embed directories](https://bun.sh/docs/bundler/executables#embed-directories), node binary dependencies were no longer resolved correctly even though they would still be bundled and accessible within the [`embeddedFiles` list](https://bun.sh/docs/bundler/executables#listing-embedded-files). We worked around this by using the `import * as from ... with { type: "file" };` and patching the resolver we use in our CLI. - If you have an import to a module that is used as a regular import _and_ a `with { type: "file" }`, it will either return the module in both cases _or_ the file path when we would expect only the `with { type: "file" }` import to return the path. We do read the Tailwind CSS version via the file system and `require.resolve()` in the CLI and via `import * from './package.json'` in core and had to work around this by patching the version resolution in our CLI. ```ts import packageJson from "./package.json" import packageJsonPath from "./package.json" with {type: "file"} // We do not expect these to be equal packageJson === packageJsonPath ``` - We can not customize the app icon used for Windows `.exe` builds without decompiling the binary. For now we will leave the default but one workaround is to [use tools like ResourceHacker](https://github.com/tailwindlabs/tailwindcss/pull/14270/commits/698d9c4bd182391adb4b236f19a539aff13f78f9) to decompile the binary first. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-09-02 15:23:46 +02:00
},
"__notes": "These binary packages must be included so Bun can build the CLI for all supported platforms. We also rely on Lightning CSS and Parcel being patched so Bun can statically analyze the executables.",
"devDependencies": {
Bump dependencies (#19608) This PR bumps a bunch of dependencies. This also moves a few dependencies that we use in multiple packages to the pnpm catalog. Closes: #19603, #19604, #19576, #19575, #19573, #19565, #19547, #19546, #19545, #19609, #19581, #19620, #19619 - #19603 - #19604 - #19576 - #19575 - #19573 - #19565 - #19547 - #19546 - #19545 - #19609 - #19581 - https://github.com/tailwindlabs/tailwindcss/pull/19620 - #19620 - #19619 ## Test Plan All tests in CI should still pass. [ci-all]
2026-02-04 12:38:50 +01:00
"@parcel/watcher-darwin-arm64": "^2.5.6",
"@parcel/watcher-darwin-x64": "^2.5.6",
"@parcel/watcher-linux-arm64-glibc": "^2.5.6",
"@parcel/watcher-linux-arm64-musl": "^2.5.6",
"@parcel/watcher-linux-x64-glibc": "^2.5.6",
"@parcel/watcher-linux-x64-musl": "^2.5.6",
"@parcel/watcher-win32-x64": "^2.5.6",
Bump dependencies (#20095) This PR bumps some of our dependencies, common dependencies were moved to pnpm's `catalog` feature. Closes #20092 Closes #20085 Closes #20075 Closes #20066 Closes #20062 ## Test plan - All tests still pass - Each dependency was published some time ago. Webpack has an even newer version that was published <15min ago. Will update that one later. [ci-all]
2026-05-21 17:58:55 +02:00
"@types/bun": "^1.3.14",
"bun": "^1.3.14",
Upgrade `lightningcss` to `1.29.2` in Standalone (#17169) Closes #17162 Closes #17163 Closes #17164 Closes #17165 Closes #17166 Closes #17167 Noticed that there was a second place pulling in the lightningcss version numbers that wasn't covered by the previous upgrade PR. Thankfully the APIs of the node bindings are still compatible. To avoid this mistake in the future I also exported these sub-packages as a workspace dependency so all the version strings appear right next to each other.
2025-03-13 11:18:06 +01:00
"lightningcss-darwin-arm64": "catalog:",
"lightningcss-darwin-x64": "catalog:",
"lightningcss-linux-arm64-gnu": "catalog:",
"lightningcss-linux-arm64-musl": "catalog:",
"lightningcss-linux-x64-gnu": "catalog:",
"lightningcss-linux-x64-musl": "catalog:",
"lightningcss-win32-x64-msvc": "catalog:"
Add standalone CLI (#14270) This PR adds a new standalone client: A single-binary file that you can use to run Tailwind v4 without having a node setup. To make this work we use Bun's single-binary build which can properly package up native modules and the bun runtime for us so we do not have to rely on any expand-into-tmp-folder-at-runtime workarounds. When running locally, `pnpm build` will now standalone artifacts inside `packages/@tailwindcss-standalone/dist`. Note that since we do not build Oxide for other environments in the local setup, you won't be able to use the standalone artifacts for other platforms in local dev mode. Unfortunately Bun does not have support for Windows ARM builds yet but we found that using the `bun-baseline` runtime for Windows x64 would make the builds work fine in ARM emulation mode: ![Screenshot windows](https://github.com/user-attachments/assets/5b39387f-ec50-4757-9469-19b98e43162d) Some Bun related issues we faced and worked around: - We found that the regular Windows x64 build of `bun` does not run on Windows ARM via emulation. Instead, we have to use the `bun-baseline` builds which emulate correctly. - When we tried to bundle artifacts with [embed directories](https://bun.sh/docs/bundler/executables#embed-directories), node binary dependencies were no longer resolved correctly even though they would still be bundled and accessible within the [`embeddedFiles` list](https://bun.sh/docs/bundler/executables#listing-embedded-files). We worked around this by using the `import * as from ... with { type: "file" };` and patching the resolver we use in our CLI. - If you have an import to a module that is used as a regular import _and_ a `with { type: "file" }`, it will either return the module in both cases _or_ the file path when we would expect only the `with { type: "file" }` import to return the path. We do read the Tailwind CSS version via the file system and `require.resolve()` in the CLI and via `import * from './package.json'` in core and had to work around this by patching the version resolution in our CLI. ```ts import packageJson from "./package.json" import packageJsonPath from "./package.json" with {type: "file"} // We do not expect these to be equal packageJson === packageJsonPath ``` - We can not customize the app icon used for Windows `.exe` builds without decompiling the binary. For now we will leave the default but one workaround is to [use tools like ResourceHacker](https://github.com/tailwindlabs/tailwindcss/pull/14270/commits/698d9c4bd182391adb4b236f19a539aff13f78f9) to decompile the binary first. --------- Co-authored-by: Jordan Pittman <jordan@cryptica.me> Co-authored-by: Robin Malfait <malfait.robin@gmail.com>
2024-09-02 15:23:46 +02:00
}
}
Reference in a new issue Copy permalink