shadcn/ui source code architecture

In this lesson, you will learn about the Shadze UI library architecture and how it is built in structure. The Shadze UI repository is an open source project, it's a set on GitHub, and it's publicly available. It's licenses MIT, meaning you can use it for free, modify it and contribute to it. Contributing to open source projects is a great way to learn and grow as a developer, so it's a great way to give back to the community. Contributing to open source projects can be intimidating. The codebase is often large and complex, and the community can be unwelcoming, but it doesn't have to be this way. The Shadze UI project is a very welcoming community, and the codebase is well organized and easy to understand. Understanding a project architecture and how it is built at a high level helps me the most going into large codebase has at my work. Once you know the high levels, you can start to dig into the details. In this module, you will learn how the Shadze UI project is structured, and in the next lesson, you will learn how to set up your developer environment, find contribution opportunities, and make changes to the codebase. The Shadze UI project is a monorepo that contains a collection of packages and applications using two-brew apple, the tool that helps managing monorepros. The repository includes a documentation website under apps/www, a component registry, which is the core of the library. We are going to talk about it more in a second under apps/www/registry, and the CLI, under packages CLI. We look at it in a second. The Shadze UI registry is the library core. It contains the source code for all the available components in the library. You can consider it the single source of truth, or Shadze UI component collection source code. The registry defines the component source file, separated based on the style, if you remember, for the first module. The component examples, which is being rendered in the documentation, and the registry metadata. The metadata includes an array with all the components that are available in the library, a registry schema, and the core of the finish-in, a list of styles available, and a list of pre-made themes that the documentation offers. We can go to GitHub and take a look. I'm inside the Shadze UI repository, and going to the apps/www folder inside the registry. We can open the schema.ts file. The file defines the registry schema, which is an array of registry and re-sch ema, and it's defined using Zod, which we should already be familiar with. The schema shapes includes the component name, for example, the badge component , the description, the dependencies from NPM and the dev dependencies, the files , which is the source code, and the component type, for example, a block, example, UI, or component. The pattern component, for example, is defined in the registry like this. Let's look at it. Here we can look at the actual registry. Let's try to look at the pattern. It has a name pattern, type of components, UI. It doesn't have dependencies inside the registry, meaning other components it depends on. The calendar, for example, depends on the pattern registry, and a link to the components code, imported with React lazy, and then the files, the actual component, a category, and a source. You can look at the aleradial log. It has a pattern dependency, and here is the source code of it. The CLI and the documentation site uses the registry to pull components, colors , styles, and themes, but they don't pull the components directly from the GitHub registry. They pull them from the built registry, which is the JSON file that we just saw containing all the components metadata. The registry also includes colors, which is the colors that we use for generating the theme of Shads in UI, and then we have the themes with the names and the colors in HCL, and then we have the styles right now there is only default in New York. The CLI and the documentation site uses the registry to pull components, colors , styles, and themes, but they don't pull the components directly from GitHub. They pull them from the built registry, which is the JSON file containing all the components metadata. Each entity, like component of colors, styles, and themes, has its own file in index.json file, hosted in UI.shadsin.com. Let's open the component registry, for example. We can see here a JSON with the components themselves, the name, the file, and the type, what we saw for the button, for example. It's the same file as in GitHub, but hosted on Shads in UI. Let's look at the styles. We can now see JSON returned with the default in New York styles. Let's take a look at the themes as well. The registry output is built using the build registry script in apps, WW/Scripts. It's an OJS script that reads the components source code in examples and build their JSON file. The documentation website is built using next.js, NMDX, the apps, WW/Content folder, hosts all the documentation pages written in MDX. Each component has its own MDX file, with two spatial MDX components. The component source, which uses the component file property from the registry UI array, and renders it to the documentation. And the component preview, which uses the components preview property from the registry, and the component preview, which uses the components files property from the registry examples array, and renders it in the documentation. The CLI is the index TS file. The CLI is hosted in packages CLI. Inside the index.ts file is the entry point for the CLI, and it's in the exact table node.js script. The CLI code uses the commander package to build a vulnerable node.js script. Each command defined in a separate file under the commands folder, here. And the index.ts file is the entry point for the CLI. As you can see in the ed command, it is doing what we mentioned in the second module. Looking for the component in the registry, selected component, it goes through the options, and try to find it based on the name. And then pulling it, the registry also includes an example array. And an example for each component, there can be multiple examples for each component, so let's take the button, for example. And we have a button demo, a button secondary, a button destructive, and more and more. And they all have a registry dependency, which is the button, and there is a TS 6 file, which define the examples code. Let's go and see that. If we go to the examples folder. For example, the button example. We can simply see the code that will be rendered inside the documentation. In the next lesson, you will learn how to run the ShadCNUI environment and contribute to the library.