Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Enable CSS nesting syntax by default when using Tailwind #10116

Merged
merged 7 commits into from
Mar 7, 2024
Merged

Enable CSS nesting syntax by default when using Tailwind #10116

merged 7 commits into from
Mar 7, 2024

Conversation

cannikin
Copy link
Member

@cannikin cannikin commented Mar 5, 2024

I don't think this plugin existed when we first created the Tailwind UI setup command, but it does now, and is super handy!

This lets you use nested CSS syntax in your index.css right after you install Tailwind.

Trying to nest without this plugin seems to work in development, but you'll get a warning message in the console each time you save your .css file.

.button {
  @apply flex items-center px-4 py-2;

  .icon {
    @apply w-4 h-4;
  }

  span {
    @apply text-sm;
  }
}

@cannikin cannikin added topic/generators-&-scaffolds release:feature This PR introduces a new feature labels Mar 5, 2024
@cannikin cannikin added this to the next-release-patch milestone Mar 5, 2024
@cannikin cannikin added the fixture-ok Override the test project fixture check label Mar 5, 2024
jtoar
jtoar reviewed Mar 7, 2024
View reviewed changes
CHANGELOG.md Outdated Show resolved Hide resolved
@cannikin cannikin enabled auto-merge (squash) March 7, 2024 16:59
@cannikin cannikin merged commit 6b81681 into main Mar 7, 2024
41 checks passed
@cannikin cannikin deleted the rc-tailwind-nesting branch March 7, 2024 17:46
jtoar added a commit that referenced this pull request Mar 8, 2024
@jtoar
chore(release): try changesets instead of changelog (#10138)
f5d97e0 
The newish changelog workflow has personally saved me a lot of time and
is half the reason we were able to release so many times on a moment's
notice last week. But it's prone to merge conflicts, both in this repo
and in the release tooling (most cherry picks from the main branch to
the next branch had merge conflicts because of the changelog) so it's
not going to scale out much more. But it's proved it's usefulness.

I tried Changesets proper—seemed like the obvious choice and @ahaywood
even independently came up with the idea—but it's overkill. I don't want
to have to associate a semver with a PR (we use milestones for that). I
also don't want to have to pick which packages we're versioning. Right
now it's always all of them. And without the tooling or without using
git, there's no obvious way to tie a changeset back to the PR that made
it. (Maybe one of the changeset changelog packages do this, but config.)
All I really want is what we're doing right now without the merge
conflicts, so I spiked on a small script to generate a minimal
changeset:

```
yarn changesets 10116
yarn changesets #10116
```

The idea is that we'll do what we've been doing, but just via that
command. It'll write a file to `.changesets/three-random-words.md`, and
we'll put our release notes for the PR there. The release tooling can
aggregate them into release notes at the time of release.

The main con is that we can't see all the unreleased changes in linear
order in one file. But tradeoffs. It's definitely worth not having to
put up with merge conflicts.
ahaywood pushed a commit that referenced this pull request Mar 8, 2024
@cannikin @ahaywood
Enable CSS nesting syntax by default when using Tailwind (#10116)
1a8d5e3 
I don't think this plugin existed when we first created the Tailwind UI
setup command, but it does now, and is super handy!

This lets you use [nested CSS
syntax](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_nesting/Using_CSS_nesting)
in your `index.css` right after you install Tailwind.

Trying to nest without this plugin seems to work in development, but
you'll get a warning message in the console each time you save your
`.css` file.

```css
.button {
  @apply flex items-center px-4 py-2;

  .icon {
    @apply w-4 h-4;
  }

  span {
    @apply text-sm;
  }
}
```
ahaywood pushed a commit that referenced this pull request Mar 8, 2024
@jtoar @ahaywood
chore(release): try changesets instead of changelog (#10138)
7961108 
The newish changelog workflow has personally saved me a lot of time and
is half the reason we were able to release so many times on a moment's
notice last week. But it's prone to merge conflicts, both in this repo
and in the release tooling (most cherry picks from the main branch to
the next branch had merge conflicts because of the changelog) so it's
not going to scale out much more. But it's proved it's usefulness.

I tried Changesets proper—seemed like the obvious choice and @ahaywood
even independently came up with the idea—but it's overkill. I don't want
to have to associate a semver with a PR (we use milestones for that). I
also don't want to have to pick which packages we're versioning. Right
now it's always all of them. And without the tooling or without using
git, there's no obvious way to tie a changeset back to the PR that made
it. (Maybe one of the changeset changelog packages do this, but config.)
All I really want is what we're doing right now without the merge
conflicts, so I spiked on a small script to generate a minimal
changeset:

```
yarn changesets 10116
yarn changesets #10116
```

The idea is that we'll do what we've been doing, but just via that
command. It'll write a file to `.changesets/three-random-words.md`, and
we'll put our release notes for the PR there. The release tooling can
aggregate them into release notes at the time of release.

The main con is that we can't see all the unreleased changes in linear
order in one file. But tradeoffs. It's definitely worth not having to
put up with merge conflicts.
@jtoar jtoar modified the milestones: next-release-patch, v7.1.1 Mar 8, 2024
jtoar pushed a commit that referenced this pull request Mar 8, 2024
@cannikin @jtoar
Enable CSS nesting syntax by default when using Tailwind (#10116)
b358096 
I don't think this plugin existed when we first created the Tailwind UI
setup command, but it does now, and is super handy!

This lets you use [nested CSS
syntax](https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_nesting/Using_CSS_nesting)
in your `index.css` right after you install Tailwind.

Trying to nest without this plugin seems to work in development, but
you'll get a warning message in the console each time you save your
`.css` file.

```css
.button {
  @apply flex items-center px-4 py-2;

  .icon {
    @apply w-4 h-4;
  }

  span {
    @apply text-sm;
  }
}
```
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@jtoar jtoar jtoar approved these changes

Assignees
No one assigned
Labels
fixture-ok Override the test project fixture check release:feature This PR introduces a new feature topic/generators-&-scaffolds
Projects
None yet
Milestone
v7.1.1
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@cannikin @jtoar