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",
v4.0.0-beta.10 (#15691) Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
2025-01-21 11:19:28 -05:00
"version": "4.0.0-beta.10",
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",
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
"@tailwindcss/cli": "workspace:^",
Update @tailwindcss/forms 0.5.9 → 0.5.10 (minor) (#15627)
2025-01-15 10:50:29 +01:00
"@tailwindcss/forms": "^0.5.10",
Update @tailwindcss/typography to version 0.5.16
2025-01-15 09:56:08 +00:00
"@tailwindcss/typography": "^0.5.16",
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",
Update enhanced-resolve 5.17.1 → 5.18.0 (minor) (#15582) 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? #### ✳️ enhanced-resolve (5.17.1 → 5.18.0) · [Repo](https://github.com/webpack/enhanced-resolve) <details> <summary>Release Notes</summary> <h4><a href="https://github.com/webpack/enhanced-resolve/releases/tag/v5.18.0">5.18.0</a></h4> <blockquote><h3 dir="auto">Features</h3> <ul dir="auto"> <li>Added wildcards support for aliases</li> </ul></blockquote> <p><em>Does any of this look wrong? <a href="https://depfu.com/packages/npm/enhanced-resolve/feedback">Please let us know.</a></em></p> </details> <details> <summary>Commits</summary> <p><a href="https://github.com/webpack/enhanced-resolve/compare/247edebc909040ff99200108f7165e57f4fac2b1...27e457a905776154c9c0f75bc0f822eeab36d2c8">See the full diff on Github</a>. The new version differs by 9 commits:</p> <ul> <li><a href="https://github.com/webpack/enhanced-resolve/commit/27e457a905776154c9c0f75bc0f822eeab36d2c8"><code>chore(release): 5.18.0</code></a></li> <li><a href="https://github.com/webpack/enhanced-resolve/commit/88ceebe3cca0a054786f12659f5239f377087f8e"><code>feat: add wildcards support for aliases</code></a></li> <li><a href="https://github.com/webpack/enhanced-resolve/commit/35b67ce83434be840c6af0012449d94130ee4dd7"><code>feat: add wildcards</code></a></li> <li><a href="https://github.com/webpack/enhanced-resolve/commit/4fbcfa1c831858b495b7ac7835cb3a9f10496495"><code>chore(deps): bump cross-spawn from 7.0.3 to 7.0.6</code></a></li> <li><a href="https://github.com/webpack/enhanced-resolve/commit/572a54f0c68dcf64a017433c188eee047a3cfea2"><code>chore(deps): bump cross-spawn from 7.0.3 to 7.0.6</code></a></li> <li><a href="https://github.com/webpack/enhanced-resolve/commit/af4e2fb155b0e885ec50f7a631f3298fdc1c08ec"><code>ci: add Node.js v23</code></a></li> <li><a href="https://github.com/webpack/enhanced-resolve/commit/bf443c04acc913461c033c1f8af1ab0a58b770ca"><code>ci: add Node.js v23</code></a></li> <li><a href="https://github.com/webpack/enhanced-resolve/commit/72999caf002f6f7bb4624e65fdeb7ba980b11e24"><code>chore(deps): bump micromatch from 4.0.5 to 4.0.8</code></a></li> <li><a href="https://github.com/webpack/enhanced-resolve/commit/fbee162cc291a84e5f711f9d7152985a904fda2f"><code>chore(deps): bump micromatch from 4.0.5 to 4.0.8</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-01-09 17:26:48 +01:00
"enhanced-resolve": "^5.18.0",
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
"tailwindcss": "workspace:^"
},
"__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": {
Upgrade `@parcel/watcher` to `2.5.0` (#14978) This PR upgrades parcel watcher to 2.5.0. Closes #14957 Closes #14958 Closes #14969 Closes #14970 Closes #14971
2024-11-13 11:38:43 +01:00
"@parcel/watcher-darwin-arm64": "^2.5.0",
"@parcel/watcher-darwin-x64": "^2.5.0",
"@parcel/watcher-linux-arm64-glibc": "^2.5.0",
"@parcel/watcher-linux-arm64-musl": "^2.5.0",
"@parcel/watcher-linux-x64-glibc": "^2.5.0",
"@parcel/watcher-linux-x64-musl": "^2.5.0",
"@parcel/watcher-win32-x64": "^2.5.0",
Update @types/bun 1.1.14 → 1.1.16 (patch) (#15618)
2025-01-14 11:25:18 +01:00
"@types/bun": "^1.1.16",
Add musl binaries to the Standalone CLI (#15567) Closes #15031 This adds musl binaries for the Standalone CLI on Linux aarch64 (ARM 64-bit) and x86_64 (Intel/AMD 64-bit).
2025-01-09 09:24:33 -05:00
"bun": "1.1.43",
Upgrade `lightningcss` to `1.29.1` in standalone package (#15641) Closes #15636 Closes #15638 Closes #15637 I noticed that I forgot to update the bundled `lightningcss` dependencies in the `standalone` project. This makes sure we have the same version everywhere.
2025-01-16 16:06:08 +01:00
"lightningcss-darwin-arm64": "^1.29.1",
"lightningcss-darwin-x64": "^1.29.1",
"lightningcss-linux-arm64-gnu": "^1.29.1",
"lightningcss-linux-arm64-musl": "^1.29.1",
"lightningcss-linux-x64-gnu": "^1.29.1",
"lightningcss-linux-x64-musl": "^1.29.1",
"lightningcss-win32-x64-msvc": "^1.29.1"
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