Why my UI components ship as source

Installing an ns-ui component places its source in your project. You can open the file, change the interaction, and read the code that runs on your page.

The registry provides the starting point. After installation, the component belongs to the application using it.

That is the model I wanted for pieces of UI I kept rebuilding: galleries, comparison controls, and small interactions that need to fit the surrounding page.

The interesting changes are usually local

A gallery may need different spacing. A motion effect may need a shorter duration. A control may need to respond to the data model already in the application.

When the source is there, those changes happen in the component itself. I can follow the event handler, inspect the styles, and adjust the behavior where it is defined.

That matters for the work ns-ui collects. The interaction is often the reason to install the component, so the interaction needs to be editable.

Source ownership has a maintenance cost

Copying source does not make maintenance disappear.

Once a component is changed locally, a future registry update needs review. The person using it has to decide which upstream changes to bring in and how those changes fit their version.

There can still be npm dependencies. The distinction is that the installed component runs from local source, without an ns-ui runtime dependency. The CLI and MCP server help with discovery and installation.

I want that trade-off to be clear before someone installs it.

The preview needs to show the actual behavior

A screenshot can show a good resting state while missing the reason a component exists.

My registry checks include interaction states such as hover and focus. A component advertised around an interaction should visibly respond to it. Previews should show the implemented component, so someone can judge what they are about to bring into their project.

Source access helps after installation. Accurate previews help before it.

Make the catalog readable too

ns-ui also exposes its catalog through /llms.txt and /llms-full.txt. Those descriptions give an agent another way to discover the components and their installation commands.

The useful part is specificity: what the component does, when it fits, and how to get it. A catalog full of interchangeable descriptions leaves the selection problem with the user.

The registry and source repository show the result. My goal is a component someone can inspect, adapt, and keep using inside their own project.