I am seeing v6 tags - roadmap?

[cstrat]

Would love to see what is planned for the project.

[akleiner2]

Hey @cstrat -- good eyes there, we've been very hard at work on v6 internally. At a very high level, we're targeting early in 2021 to cut a formal v6 release. We're still figuring out where to draw the line in the sand as for what should be included, but at the moment, the two big overhauls that we're looking to include as a part of v6:

• Complete theming support: We're still hardening the APIs here, but we're really excited about this. Typesafe ways to customize the appearance of most EG components.
• Brand new / more streamlined docs site: This'll include more complete + streamlined component documentation, and start to lay the foundation for quicker prototyping in the future.

There are some general framework-health stuff (things like improving test coverage, cleaning up / hosting Storybook), component consistency, and higher-level compositions that are in the works, but I think at the bare-minimum, the above two are the big includes for v6. Let us know if you have any other questions

[cstrat]

Theming support will be amazing, very excited for that! Thanks for all the great work you guys have been doing.

[jordn]

@akleiner2 thanks for your continual work on this design system in public. I've tried a few now and I've come back to this one as I think it is the cleanest.

I'm glad you're prioritising theming support. Frankly that's my most important requirement from a design system, beyond the basics which they all do.

One 2c of input. In my eyes, Tailwind is emerging as a new standard for CSS (by avoiding it and using utility classes!). My preferred workflow is to create a component and litter it with these css classnames to style. But I don't want to be recreating all the components of a design system either and would prefer to use an off-the-shelf system and tweak and style with tailwind classes as needed. Curious if you're thinking about this workflow at all?

[akleiner2]

@jordn Do you mind giving a more concrete example of what you had in mind? Are you talking about trying to accomplish theming via using something like tailwind classnames? Or are you talking about "unstyled" Evergreen components that you could just bring your own styles / theming to?

Evergreen is built off a very flexible UI primitive ui-box, so most of the non-special utility classes (i.e. responsiveness, dark-mode) can be directly passed as props to all Evergreen components, so the need to write CSS out of the box should be relatively minimal, as well.

[lightwave]

Any breaking changes we should anticipate in v6?

[grandevel]

It's great that v6 is now out of the door - but is there a roadmap you guys at Segment can share with us? It kinda feels like this library - great as it is - is hard to contribute to as it is so 'internal to segment' - stuff comes out when it comes out, without any real notice or plan. Anything you can share about what is coming in the next 6-12 months?

[akleiner2]

Hey @grandevel we're working on being able to share a rough, external roadmap so that others can understand the direction we're heading. It's a bit tough balancing our internal needs with Evergreen with the needs of open source. Evergreen is primarily influenced by our own internal design direction, and product-engineering stress tests internally. That being said, a few themes that will likely end up on the roadmap in the coming months:

• Reliable Releases: Ensuring that every release of Evergreen is well-tested, and well-vetted before making its way to the NPM or Yarn registry. Testing is the primary metric here. We don't have much in the form of even smoke tests (i..e "does this component even render, given these inputs?) at the moment, but we're hoping to change that immediately. Same thing with our docs site
• Accessibility: Making sure that most / all of Evergreen's components conform to WAI-ARIA, and WCAG standards. Enforcing these through testing, linting, and even some custom tooling.
• Patterns: Thinking through the highest-order compositions of Evergreen components. We're working on the right APIs for an Empty State pattern right now, but there's work around error states, and more coming up.

I know this isn't a formal roadmap, but these are some of the things that we're thinking about. There are other framework health things like migrating most APIs to be "token-aware", migrating the codebase to TS, etc, but hopefully this gives a sense of where our heads are at.