Deprecate short css in favour of arbitrary properties

[ben-rogerson]

Now that we can use the new arbitrary properties from tailwindcss its easy to see it's extremely similar to twin's "short css" feature which both let you write completely custom css:

tw`caret-color[black]`; // Short css
tw`[caret-color:black]`; // Arbitrary properties

// ↓ ↓ ↓ ↓ ↓ ↓

({
  "caretColor": "black"
});   // Short css

({
  "caretColor": "black"
}); // Arbitrary properties

It made sense to offer only a single "custom css syntax" and arbitrary properties made the most sense to go with.

So now when short css is found, twin throws a helpful message:

MacroError: /Users/.../App.tsx: 

✕ Bad: color[var(--myvar)]
✓ Good: [color:var(--myvar)]

Short css has been deprecated and replaced by arbitrary properties
Read more at https://twinredirect.page.link/short-css

Enable short css again with this twin config: { "disableShortCss": false }

I'll keep short css around a couple more versions (perhaps minors) then I'll fully remove it and the cs prop (a prop for adding short css).

[mosesoak]

Hey Ben -- I noticed this feature and wanted to check it out, so I made a build, and it works so far, including with breakpoints -- nice work!

It breaks syntax highlighting though -- is this expected for now? I'm using the extensions lightyen.tailwindcss-intellisense-twin and styled-components.vscode-styled-components.

[mosesoak]

Codemod...?

One major question this begs for me is upgrading existing projects. There are hundreds of short styles in our codebase. For now I'm setting disableShortCss: false, but thinking about the future and keeping things current.

I think it could be done by writing a codemod. I tried writing a regex in vs code and got pretty close, but it doesn't seem possible to loop through to replace multiple matches within a single tw string (many of ours are multiline), and running the replace multiple times ends up getting false matches and garbage out.

Just a thought -- I'd be game to help write the codemod if that's not something you have time for, but releasing a big change like this might be a little tough without it.

[mosesoak]

So here's a potential snag for you on this. Our team has used a bunch of short-short-css:

pl-[1.1rem]

...that actually works. Not sure if it was an official part of the twin API, but it's been used freely.

Currently this new tw 3 syntax will force us to unwind all of these to full prop names like [padding-left:1.1rem].

While that is more in line with TW proper, it presents a bigger challenge for code-modding and sort of removes a nifty side feature of twin for us.

Thoughts?

[ben-rogerson]

I've also been pondering about a codemod - feel free to flick what you have over to me, perhaps I can finish it off before 3.0.0.

So here's a potential snag for you on this. Our team has used a bunch of short-short-css: pl-[1.1rem]

Just making sure you know the above is an arbitrary tailwind class - the short css version is padding-left[1.1rem].

So the conversion from short css to arbitrary properties will be:

tw`padding-left[1.1rem]`
// ↓ ↓ ↓ ↓ ↓ ↓
tw`[padding-left:1.1rem]`

[ben-rogerson]

It breaks syntax highlighting though -- is this expected for now? I'm using the extensions lightyen.tailwindcss-intellisense-twin and styled-components.vscode-styled-components.

@lightyen has added support for this in the new prerelease. You need to install it manually as the prerelease isn't available via vscode:

[mosesoak]

Just making sure you know the above is an arbitrary tailwind class

@ben-rogerson oh so these could remain as is after the old short-css syntax gets deprecated?