Preparing for version 3.0

[jonkoops]

With all the outstanding issues resolved except those that might introduce breaking changes, I think it's time to we start branching off for version 3, and consider what changes should be included. There is already a next branch, but it has become rather stale, and most of the code has already been ported back to main.

My proposal would be to delete the next branch, and instead create a v2 branch that takes the current state of main, so we can continue to maintain and release 2.x in the future (although this would likely only include critical bug and security fixes). We can then use the main branch to further develop version 3.0 until it is deemed ready for release.

I've also created a milestone for version 3.0, which should make it a bit easier to track.

[jonkoops]

@dcousens @JedWatson WDYT? Is this strategy something you can get behind as well?

[dcousens]

Sounds good to me, but I wouldn't bother with a v2 branch unless we need to go back to that branch - as you say, it's unlikely. git has the history.

[jonkoops]

Perfect, I've created a v2.0 branch for now (we can always delete it), so that if we make changes in the docs we can link there for users that might want to read the 'legacy' docs.

[jonkoops]

Let's keep this issue open to coordinate the work needed for 3.0 in general.

[jonkoops]

I went ahead and deleted the next branch, as there was nothing of great value there left to port over.

[dumbmatter]

Stupid idea maybe, but would it make sense to just say the next version of classnames is clsx? Or is there going to be some advantage of classnames v3 over clsx? Currently clsx claims to be faster and smaller, and it's also now more popular.

[jonkoops]

Or is there going to be some advantage of classnames v3 over clsx?

I personally have been toying with the idea of simplifying the API of classnames to reduce the complexity of our code, and hopefully increase performance while we're at it. But this will still require some discussion on what the final implementation should be.

I'd also like to offer an even more basic version of classnames that only accepts strings (much like clsx), as you can pretty much express all you need with string | false, but might be considered non-preferential for most users stylistically (objects are kinda nice).

Aside from that we offer style binding (e.g. for CSS modules), and a unique 'dedupe' alternative. We still have to decide what needs to be preserved from this, or revisited in API. I myself would like to refactor the style binding variant to have a more intuitive API, I think there is still value in that for our users.

As for the 'dedupe' variant, I don't really see any practical cases where you would want to dedupe classes, or even run into a scenario where your expressions have become so complex it would occur naturally. Also the impact of having a class duplicated is virtually non-existent, but perhaps there are historical reasons for this.

Stupid idea maybe, but would it make sense to just say the next version of classnames is clsx?

I don't think this is a stupid idea at all, one of the many issues in the JavaScript ecosystem is the choice overload that persists. And we have a lot of overlap with clsx, so it does make a lot of sense to see if we can combine our efforts here.

I think there are a couple of differences between our philosophies though (note personal opinion ahead), we both strive for excellent performance (note we are pretty competitive), but clsx obsesses a bit about file-size to the point where I think the returns are diminishing, we're only shipping a single utility function after all.

Another point we differ is that clsx is backwards compatible all the way back to Node.js v0.10.0 and Internet Explorer 8. Which is impressive, but I sincerely doubt that it is being executed in any such runtime that still exists in the wild. I prefer more modern syntax support if that can open up the gates to better performance (e.g. using Set for de-duplication), but further testing is required to confirm this is the case.

We also have plans to possibly drop UMD and CommonJS and favor a purely ESM distribution (#349), as I believe there is a lot of value in finally settling on a common set of primitives around modules. Note, we will continue to support v2 for the foreseeable future to bridge that gap.

That said, perhaps our differences can be settled, APIs combined, and we can make a better alternative to all involved. For now at least work will continue on classnames, and we're actively looking to the future, whatever that may be.

cc @lukeed @jorgebucaran