Add options to match attributes by prefix and suffix

[ealexandros]

Hey! This PR introduces a new feature to enhance how the plugin discovers attributes containing Tailwind classes.

Motivation

The plugin currently handles standard attributes like class and className very well. This change aims to expand that capability to support a wider range of projects that use their own unique naming conventions for styling.

For instance, some frameworks use prefixed attributes for dynamic classes, while component libraries often use props with specific suffixes (e.g., wrapperClassName, iconClass). This PR allows the plugin to recognize and sort classes within these types of custom attributes, making it more adaptable to different coding styles.

How it Works

This is accomplished by adding two new options to the .prettierrc.json:

• tailwindAttributesStartWith: An array of strings to match attributes that begin with a given prefix.
• tailwindAttributesEndWith: An array of strings to match attributes that end with a given suffix.

Example Configuration

For example, to handle the common ..ClassName pattern, a user can update their .prettierrc.json:

{
  "plugins": ["prettier-plugin-tailwindcss"],
  "tailwindAttributesEndWith": ["ClassName"]
}

With this configuration, attributes like x-bind:class, wrapperClassName, and iconClass will now be formatted correctly.

Happy to discuss and hear any feedback.

[thecrypticace]

I think I'd rather make matches be regexes per the request in #373. That's a strictly more powerful feature.

I do need to think about how automatic dynamic stuff works with that feature though 🤔

[ealexandros]

That's a great point about regex being more powerful.

My approach was actually inspired by that issue #373. The goal was to build a simple solution that covers the majority of the examples provided there.

For instance, I noticed many of the suggested regexes were effectively checking for a common suffix (like ClassName). The endsWith option solves that pattern directly.

If a regex-based solution aligns better with the project's long-term vision, that's completely understandable.

While this PR doesn't implement the full regex support requested in #373, it resolves the most common use cases.