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.

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

v3 @apply compose in different order compared to v2 #7225

Closed
jquense opened this issue Jan 26, 2022 · 3 comments · Fixed by #7232
Closed

v3 @apply compose in different order compared to v2 #7225

jquense opened this issue Jan 26, 2022 · 3 comments · Fixed by #7232
Assignees

Comments

@jquense
Copy link
Contributor

jquense commented Jan 26, 2022

What version of Tailwind CSS are you using?

v3.0.14

Reproduction URL

https://play.tailwindcss.com/mPg4EIVZLy?file=config

Describe your issue

Previously (v2) when @applying a class and then explicitly added a property that was shared by the applied class the later property would win. In v3 the applied classes always seem to be added after the component definition.

See in the linked playground in v2 the "fails" class is blue vs v3 where it's red. This feels like it's a bad behavior but i don't know if it's intentional or expected.

@vitorrd
Copy link
Contributor

vitorrd commented Jan 27, 2022

What version of Tailwind CSS are you using?

v3.0.14

Reproduction URL

https://play.tailwindcss.com/mPg4EIVZLy?file=config

Describe your issue

Previously (v2) when @applying a class and then explicitly added a property that was shared by the applied class the later property would win. In v3 the applied classes always seem to be added after the component definition.

See in the linked playground in v2 the "fails" class is blue vs v3 where it's red. This feels like it's a bad behavior but i don't know if it's intentional or expected.

I am almost sure this was working in a previous iteration of v3. This may have been broken by recent changes to how the rules are parsed, as this is probably not intended behavior since JS object key order is ensured among non-numeric keys.
A curious one, though.

@RobinMalfait
Copy link
Contributor

Hey! Thank you for your bug report!
Much appreciated! 🙏

This should be fixed by #7232, and will be available in the next release (probably later today).

You can already try it by using the insiders build npm install tailwindcss@insiders or yarn add tailwindcss@insiders.

@jquense
Copy link
Contributor Author

jquense commented Jan 27, 2022

Awesome thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants