npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@one-market/ui-kit

v1.0.5-katana

Published

## Consuming / Using this project

Readme

UI Kit

Consuming / Using this project

Contexts

Components in this project rely on several contexts that you need to set up.

i18n keys

Contributing to this project

General Principles

  • Stories in storybook are organized following atomic design.
  • The props on exported components should be limited to those that are needed and required by design.
  • Exposed props should have a corresponding story demonstrating usage
  • Exported components should never expose properties that allow setting arbitrary CSS or styling

Write correct HTML

  • Components should render correct HTML whenever possible
  • Components that can be used for navigation and accept an onClick handler must also accept link props, and render an anchor tag.
  • Sections with correct heading levels should be used to ensure the document is properly formatted
    • Each page should only have one h1
    • Pages should not have a h2 beneath an h6 in the same section

Colors, spacing, and sizing components

  • Any exported component that provides coloring should do so by generic properties with named values. For example, color="primary" or color="error".
  • Any exported component that provides customizing properties related to sizing should use named values for the sizes:
    • If the size determines many aspects of the component's styling, use size prop with appropriate values. For example, on button components, size="medium" will give a medium-sized component
    • If sizing is more granular and only affects a single property, such as border radius, padding, or margin, use individual properties. For example, p="small" will render a component with small padding.
      • An object syntax should also be provided when more granularity is needed. For example, p={{ y: 'small' }} sets a small top/bottom padding for the element.

Sizing in theme

  • Specify all font sizes in rem. Specify other sizes, such as border width, border radius, padding, and margin in px.

Default values

  • For component props that affect styling, provide defaults whenever possible. Not specifying a default may cause an underlying component such as mui selecting an unintended default value.
  • Defaults can be determined based on other props. For example, color may be defaulted based on the variant given.

Partially generic components

  • Sometimes, a common set of properties are set together on a component, but introducing a new prop to handle the defaulting is too cumbersome, or could cause confusion. For example, buttons in the system used for confirming and canceling actions should always have the same props. These are really variations, but the button component already has a prop called variant. Adding a similarly named property is likely to lead to confusion. Therefore, a ConfirmButton and CancelButton are exported.
    • Why not use PrimaryButton and SecondaryButton? This can also cause confusion since primary and secondary are values for color on button. Using separate components by intention also allows us to default the label, and restrict props further to just those from the base button component that make sense.

Running storybook

To run storybook:

This will launch storybook at http://localhost:6006

To build storybook:

To manually build components (as will be published to npm):

Building and publishing

This project uses semantic versioning.

Updating the version number and publishing is handled automatically through github actions that are triggered by pull requests.

When developing, use the following workflow:

Local Development

When developing locally, you can see your changes in a project that consumes the ui-kit by using npm link.

To link:

  • In ui-kit, run npm run build to create dist folder
  • From dist folder, run npm link
  • In companion project (e.g., ktt_web), run npm link "@one-market/ui-kit"

To unlink

  • In companion project, run npm unlink --no-save <module_name>
  • In ui-kit, run npm unlink