Prepare the 4.0.16 release.
~~Also added a commit to mark the `--value('…')` and `--modifier('…')`
with literals strings as an experimental feature (aka not shipped in
this PR). But we can revert that commit if we still want to ship it in
4.0.16 instead of 4.1.~~
---------
Co-authored-by: Philipp Spiess <hello@philippspiess.com>
<!--
👋 Hey, thanks for your interest in contributing to Tailwind!
**Please ask first before starting work on any significant new
features.**
It's never a fun experience to have your pull request declined after
investing a lot of time and effort into a new feature. To avoid this
from happening, we request that contributors create an issue to first
discuss any significant new features. This includes things like adding
new utilities, creating new at-rules, or adding new component examples
to the documentation.
https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md
-->
<!--
👋 Hey, thanks for your interest in contributing to Tailwind!
**Please ask first before starting work on any significant new
features.**
It's never a fun experience to have your pull request declined after
investing a lot of time and effort into a new feature. To avoid this
from happening, we request that contributors create an issue to first
discuss any significant new features. This includes things like adding
new utilities, creating new at-rules, or adding new component examples
to the documentation.
https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md
-->
---------
Co-authored-by: Adam Wathan <adam.wathan@gmail.com>
<!--
👋 Hey, thanks for your interest in contributing to Tailwind!
**Please ask first before starting work on any significant new
features.**
It's never a fun experience to have your pull request declined after
investing a lot of time and effort into a new feature. To avoid this
from happening, we request that contributors create an issue to first
discuss any significant new features. This includes things like adding
new utilities, creating new at-rules, or adding new component examples
to the documentation.
https://github.com/tailwindcss/tailwindcss/blob/master/.github/CONTRIBUTING.md
-->
---------
Co-authored-by: Adam Wathan <4323180+adamwathan@users.noreply.github.com>
Resolves#15977
Our `@tailwindcss/browser` build is intended to run inside a `<script>`
tag inside browsers. Because of how variable assignment within
`<script>` tags work, all variables that were defined within that script
are currently assigned on the global namespace.
This is especially troublesome as eslint uses `$` as a valid mangling
character so importing the CDN build would now redefine `globalThis.$`
which collides with many very popular JavaScript libraries.
In order to avoid polluting the global namespace, this PR changes the
build step to emit an IIFE (so all vars defined are scroped to the
function closure instead of the global namespace).
## Test plan
- Ensure UI tests still work
- <img width="533" alt="Screenshot 2025-01-28 at 16 49 27"
src="https://github.com/user-attachments/assets/1e027451-f58b-4252-bf97-c016a90eb78b"
/>
This PR adds a `main` and `browser` field for the `@tailwindcss/browser`
package.
In the package, we do have the `exports` field setup, which is an
alternative to the `main` field according to the docs:
> The "exports" provides a modern alternative to "main" …
>
> —
https://docs.npmjs.com/cli/v10/configuring-npm/package-json?v=true#exports
However, if you look at the unpkg link:
https://unpkg.com/@tailwindcss/browser, it tries to load the `index.js`
file. This is probably a bug in the unpkg resolver.
That said, if you look at other CDNs such as esm.sh, it does resolve
correctly: https://esm.sh/@tailwindcss/browser
According to the npm docs:
> If `main` is not set, it defaults to `index.js` in the package's root
folder.
>
> —
https://docs.npmjs.com/cli/v10/configuring-npm/package-json?v=true#main
This explains why unpkg is trying to load the `index.js` file.
Additionally, the npm docs also mention the `browser` field:
> If your module is meant to be used client-side the browser field
should be used instead of the main field. This is helpful to hint users
that it might rely on primitives that aren't available in Node.js
modules. (e.g. window)
>
> —
https://docs.npmjs.com/cli/v10/configuring-npm/package-json?v=true#browser
So this PR also adds that field just to be sure.
