breaking: bubbletea/lipgloss v2

[lrstanley]

[!WARNING] THIS SHOULD NOT BE MERGED UNTIL the Charm team has fully released all of the associated charm libraries. This PR is currently tagged as github.com/lrstanley/bubbletint/v2 @ v2.0.0-alpha.10. Use with:

go get github.com/lrstanley/bubbletint/[email protected]

You can find the API for v2 here: https://pkg.go.dev/github.com/lrstanley/bubbletint/[email protected]

---

🚀 Changes proposed by this PR

[!CAUTION] At a high-level, there are more breaking changes with v2 of bubbletint, than not. You will want to review the new API.

Remove Reliance on Lipgloss for color.Color

Refactored the library as a whole to support the color.Color interface directly, without relying on lipgloss, for more agnostic usage. It should now be possible to use it with many other libraries without pulling in lipgloss (and other associated dependencies), though you may still need down-sampling if you're not using bubbletea/lipgloss, to support non-true-color (or 256bit) terminals.

• This also makes it easier to use with lipgloss v2, as less conversions need to happen now. Example:

  theme := tint.TintDraculaPlus
  s := lipgloss.NewStyle().Foreground(theme.Fg)
  

• This should make things more performant.
• Should make hex codes more consistent (some themes from our datasources had 4 length hex colors, in addition to 7 length, but that should now be normalized as 7 length.
• Reduces total external dependencies for the main library down to 1.

No More Bloated Interfaces

Removed the tint interface with a huge list of both global functions, as well as methods for querying colors, and have instead opted for a more straightforward struct for storing color values.

• This has lowered the overall amount of code generated.

• Callers of the library can still implement their own interfaces.

• The global registry still works the same as before, so you don't have to manage passing the theme state across many different components.

• Rather than Registry.Blue(), you'd do one of:

  // Using custom registry. Done during initialization.
  registry := tint.NewRegistry(
      // Default tint.
      tint.TintDraculaPlus,
      // All others you want to register.
      tint.TintCatppuccinFrappe,
      tint.TintCatppuccinMocha,
      tint.TintDraculaPlus,
      tint.TintMonokaiPro,
      tint.TintTinaciousDesignDark,
  )
  
  // Use it.
  s := lipgloss.NewStyle().
      Foreground(registry.Current().BrightBlue)
  

  // Using global registry. Done during initialization.
  tint.SetTint(tint.TintDraculaPlus)
  
  // Use it.
  s := lipgloss.NewStyle().
      Foreground(tint.Current().BrightBlue)
  

  // Pick a specific tint:
  theme := tint.TintDraculaPlus // Set globally somewhere.
  
  // Use it.
  s := lipgloss.NewStyle().
      Foreground(theme.BrightBlue)
  

JSON Serializable

Tints are now fully JSON serializable.

• When marshalled, they will be stored as RGBA (to not lose the alpha value, if your tints support that).
• When unmarshalled, we support both RGBA ({"r": 255, "g": 0, "b": 0, "a": 255}), in addition to hex strings ("#ff0000"), which makes it easier for end users to add their own tints.

panic()'s OH MY!

The code now has more resilient fallbacks, reducing the potential chance that developer-error results in a panic.

Updated Examples

Examples have been updated to support bubbletea/lipgloss v2 as well. There are also more examples, like examples/load-from-file, showing how to load tints from a file, which would be useful in end-user applications.

TODO

• [x] update readme example and feature-set
• [ ] update repo settings environment config to switch from v2-exp to master, and workflow to use master as well
• [ ] add a breaking changes section to the readme to help aid with v1 -> v2 (will be done once this PR is ready for merge)
• [ ] add examples of how to use with fang and other similar libraries

🔗 Related bug reports/feature requests

• closes #9
• closes #2

🧰 Type of change

• [x] Bug fix (non-breaking change which fixes an issue).
• [x] New feature (non-breaking change which adds functionality).
• [x] Breaking change (fix or feature that causes existing functionality to not work as expected).
• [x] This change requires (or is) a documentation update.

🤝 Requirements

• [x] ✍ I have read and agree to this projects Code of Conduct.
• [x] ✍ I have read and agree to this projects Contribution Guidelines.
• [x] ✍ I have read and agree to the Developer Certificate of Origin.
• [x] 🔎 I have performed a self-review of my own changes.
• [x] 🎨 My changes follow the style guidelines of this project.
• [x] 💬 My changes as properly commented, primarily for hard-to-understand areas.
• [x] 📝 I have made corresponding changes to the documentation.
• [x] 🧪 I have included tests (if necessary) for this change.