March 2023. Meshery had the consistency problem described in Part 4 — multiple button patterns, no shared components, colors scattered across files. The team decided on Sistent as the solution. My job was to set up the development infrastructure: Storybook.
PR #7389: Storybook Initialization
The first PR was scaffolding. Install @storybook/react, configure it for Meshery’s build pipeline, write a single Button story to prove it works. The Button story was deliberately simple — not because the component was simple, but because the point was proving the infrastructure, not the component.
// The first Storybook story in Meshery
export const Primary = {
args: {
variant: 'contained',
color: 'primary',
children: 'Button',
},
};Three props. One component. The MUI Button, wrapped in a Storybook story with a theme decorator. That theme decorator was the interesting part — it wired up Meshery’s existing theme so that components in Storybook looked like components in the app. Without it, Storybook would render MUI’s default theme, and the stories would be useless for visual review.
PR #7407: AppBar & Chip
The first real component stories came three days later. AppBar and Chip — two MUI components that Meshery used everywhere but that nobody had documented or standardized.
The AppBar story exposed the first design decision: Meshery’s navigation bar was a customized MUI AppBar with a specific height, background color, and icon arrangement. None of that was written down. It existed only in the React component file, discoverable only by reading the code.
Writing the story forced the question: what is the intended API for this component? What props should it accept? What variants exist? The act of documenting the component in Storybook revealed that nobody had agreed on answers to these questions. The Storybook story became the specification — not because Storybook is a spec tool, but because writing a story requires deciding what the component is.
The Chip component was similar. MUI’s Chip has variants (filled, outlined), sizes, colors, delete handlers, avatars, icons. Meshery used maybe three of those combinations across the entire app, but which three? The story answered that.
The @storybook/addon-styling Setup
One of the more technical decisions was adding @storybook/addon-styling (now @storybook/addon-themes) to manage theme context. MUI components depend on a ThemeProvider, and without it, Storybook renders unstyled components. The addon let me configure Meshery’s light and dark themes as Storybook decorators, so every story automatically rendered in both modes.
This was my first practical experience with theming infrastructure. Not “pick light or dark colors” but “how do you propagate a theme context through a component tree so that every component resolves its colors from the same source?” The answer in MUI-land is ThemeProvider. The answer in Svelte-land (which I’d discover later) is CSS custom properties on :root. Different mechanisms, same problem: a single source of truth for visual decisions.
PRs #7621, #7653, #7723: Architecture
May 2023. The Storybook setup had grown past a few stories in the main Meshery UI directory. It needed its own home.
PR #7621 moved Storybook into a standalone directory, separating the component documentation from the application code. This seems like a file reorganization, but it was actually an architectural decision: the design system is not the app. It feeds the app, but it has its own build, its own tests, its own deployment. Sistent would eventually become its own npm package. The directory move was the first step toward that separation.
PR #7653 created a CodeMirror v6 editor story. This was the most complex story yet — a code editor with syntax highlighting, line numbers, and theme integration. It demonstrated that Storybook could handle components with significant internal state and third-party dependencies, not just simple MUI wrappers.
PR #7723 continued the pattern — more stories, more documentation, more agreement about what components should look like and how they should behave.
198+ Commits Later
By mid-2023, my Meshery contributions totaled 198+ commits across the Go backend, CI/CD pipelines, and the nascent Sistent component library. The split was roughly:
- Infrastructure: Go upgrades, dependency management, pipeline fixes
- Frontend: Storybook initialization, component stories, theme configuration
- Architecture: Directory reorganization, build separation, documentation structure
The frontend work was the minority by commit count but had outsized impact. A single well-documented Button story replaced dozens of “how should this button look?” conversations in PR reviews.
What Storybook Taught Me About Design Systems
Documentation is design. Writing a story forces you to answer questions that code doesn’t ask. What are the variants? What are the valid states? What props are required? The story is the spec.
Theme context is infrastructure. Without a ThemeProvider (or its CSS equivalent), every component is an island making its own color decisions. The theme is the network that connects them.
Separation matters early. Moving Storybook to its own directory in month two saved us from tangling the design system with the app. Every day that separation exists is a day someone doesn’t accidentally couple the two.
MUI is a design system, not a starting point for one. Meshery was built on MUI, but Sistent wasn’t “customize MUI.” It was “wrap MUI so that Meshery’s specific decisions are encoded and enforced.” The wrapping layer is where the design system lives — the defaults, the constraints, the opinions that make your product look like your product and not like every other MUI app.
This last point would influence Stratos directly. When I built acaldwell.dev’s component library, I didn’t use MUI, Radix, Shadcn, or any headless library. I wrote the components from scratch in Svelte because I’d learned at Meshery that the wrapping layer is where all the hard decisions live. If you’re going to make those decisions anyway, you might as well make them without the abstraction overhead.
This is Part 5 of 7 in the Resume Evolution series.