All right, so before we change anything inside of our project, let's go ahead and jump into our terminal and boot it up and see what it looks like. So npm run dev. We'll get our server up and running, so let's go ahead and run that.

All right, we can click on the server address right here by holding Command and clicking it, and it opens up our application inside of our browser at localhost and the default port of 3333.

And sweet, so we can see that our application's up running and working a-okay. As a next step, let's go ahead and get the core dependencies of our application installed. So that's going to be tail and CSS,

shodcm-view, which is our view component library, and then on top of that, since shodcm-view puts the components directly inside of our project, we'll go ahead and incorporate

an automatic component import and registration step within our project flow so that we don't have to worry about importing them every time that we want to use a component. So as it goes in programming,

almost immediately after we finished recording the series, shodcm-view released a brand new major version of their component library, which is version one for them. This major version change consists of a number

of breaking changes, one of which is the installation process itself. It requires a little bit more manual work on our behalf to get it set up.

And in addition to that, they've also switched from using Radex UI as their underlying UI component library, which they build all of their components on top of, to now using Reka UI.

Now Reka UI is essentially the next iteration of Radex UI. They both sound similar, they're from the same people.

It's just consider it a next major change version for them. And then they decided to change the name as well. So behaviorally, it should be similar, though there are bound to be a number of changes

in what they expect between their components, which in turn would mean a number of changes inside of the shodcm-view components between prior to version one and version one itself. So because of those two things,

I'm gonna recommend that you stick with the Radex UI version of shodcm-view for consistency with this series so that my experience matches what you'll experience

as you follow the series along. Now, unfortunately, that does mean that the command that we need to run in order to install things will vary slightly. So if we go into the installation steps,

go into Vite here, this is the documentation that we need to follow in order to get things set up in accordance with using Radex UI. And this is the exact flow that we'll walk through here

in a moment whenever we continue our regularly scheduled lesson. If we go ahead and scroll on down, however, we will see that whenever we run

their shodcm-view mpx command, we now need to @radex. This will differ from my experience in the lessons

to your experience now because of this new major change. We now need to target the old version whenever we run these commands. So note that any time that you're installing a component,

initializing shodcm-view itself, you're gonna need to @radex where I did not inside of these lessons. So where I just run mpx shodcm-view init,

I will need to run mpx shodcm-view @radex init. This same thing rings true any time that we install a component.

The new command is mpx shodcm-view @radex add, and then the component name. Whereas throughout the series,

I will just be running mpx shodcm-view add button. Without this @radex specification,

it will try to install the newer Raker UI versions, which again can and will differ from the components that I'm using throughout the series.

So whenever I install components throughout the series, I tend to use the Visual Studio Code plugin for that. Unfortunately, I don't believe that there's a way to target a specific version with that.

So you're gonna need to probably manually type the command in itself. The Visual Studio Code plugin just opened up the terminal and plopped the command in there and ran it for me.

So you'll still see the command that's actually run inside of the terminal on screen. Just remember to add the @radex qualification to that

prior to running it yourself. Okay, that should be all for the changes here. Let's go ahead and continue with the regularly scheduled lesson. So to start out with, I have a secondary tab open up here

for shodcm-view. You can find the documentation at shodcm-view.com, and you can find the installation instructions that we'll be following by clicking getting started and going to the install tab.

AdonisJS uses VEET, so we will be using the VEET instruction steps. And step one of their instructions has you create a brand new project. Well, we already have a project that we're working within,

so we're just gonna skip straight to step two, which is getting TailwindCSS installed. So we can go ahead and give that command there a copy and jump back into our terminal, stop our server, clear that out,

and paste that command in. To update this lesson slightly, TailwindCSS just released version four as of January 22nd, 2025. And at present, much of their plugin community

is not yet up to date with version four. To ensure that everything for you works the same as it has for me throughout this series, I'm gonna go ahead and recommend that you stick with TailwindCSS version three

to avoid any potential confusion or anomalies. And then later on, once you're comfortable with what's going on, you can always update the version four, which we'll be sure to have a guide out soon for that.

So to install version three, you want to do npm i -D to target this as a dev dependency, TailwindCSS, @, and then add a three in,

and it will automatically grab the latest version with a major of three. Then go ahead and tack on auto-prefixer as well. Hit enter to go ahead and run that, and you'll be all set.

Awesome, so that installed a-okay. I'm gonna go ahead and clear that out as well. Next, we're gonna want to jump into our projects. I'm gonna hide my browser away and jump back in here, go into our v-config. We'll see a red squiggly just because all of this

is on one line. If we give our project a save there, and you have ESLint configured, it will go ahead and run the fix for that to add new lines for each of those. What we need to do now is set up Tailwind

in auto-prefixer, so we can do that by doing CSS, providing an object inside of there. Tailwind and auto-prefixer are for post-CSS, which we will be using and comes pre-installed with VEAP.

So we can go ahead and specify a configuration for that right here. And specifically, we want to add them as plugins, so we'll add a plugins array there as well.

We're going to want to use the Tailwind plugin as well as the auto-prefixer plugin there. And you'll see that neither of those auto-imported for me, so I'm gonna jump up to the top of my file

and import Tailwind from TailwindCSS and import auto-prefixer from auto-prefixer. Give that a save to fix our squigglies,

and there we go. Out of the box, AdonisJS and its Inertia Starter Kit started us with an Inertia plugin that specified that we do want to use SSR,

the Vue plugin, so if you're using Vue, that will be there, and your traditional AdonisJS plugin that comes with any AdonisJS project. The resolve alias right down here

is going to allow us to import files from the Inertia directory using a alias of tilde. So for example, up here in this comment, let's say we wanted to import something

from Inertia components header. We would be able to do that in Vue via import header from your string to the tilde to specify this alias slash,

and now we're already looking inside of our Inertia directory, so we would just need to do components/header.vue there to import that file prefix that with an example there as well.

As a heads up, if you are looking at the shodcm-vue, if we scroll down a little bit, they use an at character for their alias. We're going to stick with a tilde. The differentiation there doesn't really matter at all. Either one will get the job done.

All right, let's hide that back away. This resolve alias is also defined by default inside of our Inertia TS config directory right here

with the paths under our compile options. So if you do change that to say the at character instead, you want to make that change here as well.

We're sticking with the defaults of the Inertia starter kit, so we will leave those as is. All right, so our vconfig should be all set up. shodcm-vue comes with its own configuration step

that's going to alter some things inside of a project. So we're going to want to jump inside of our CSS file inside of our Inertia directory, and just go ahead and delete this out

because it's going to add one in for us automatically. So we'll delete that there and move the trash for right now. Once we've deleted that, we can jump back inside of our terminal.

Make sure you're at the root of your application there, and let's run shodcm-vue's configuration command, mpx shodcm-vue at latest init.

We can hit enter to start this, and it's going to walk us through some questions to determine how we want it configured. So we are using TypeScript here, so we'll hit yes for that. Out of these options, we're using Vite,

so we will move forward with Vite there. We'll go ahead and stick with just the default style. This is really asking which flavor of gray you would like to use with TailwindCSS. I tend to stick with Slate, so I'll be going with that.

This is inconsequential, so feel free to select whichever one you would prefer. Then it's going to ask where our tsconfig file is located. Now, this is going to be our Inertia tsconfig

because shodcm-vue is specific to our Vue application. So we don't want to point it to our root tsconfig like the default is here, but instead to our Inertia tsconfig.

So we'll do ./inertia/tsconfig.json to ensure that it is looking inside of our Inertia directory for that tsconfig.

Then it's going to ask where our global CSS file is. This is that file that we just deleted out of our Inertia CSS directory. So we can point it to Inertia CSS,

and that file is called app.css. So we can hit enter there as well. And it'll ask us whether or not we want to use CSS variables. This will set up our Tailwind configuration in a way where it will use CSS variables,

which I tend to prefer, so I will hit yes here. Then it's going to ask where we want our Tailwind config to be located. Default is a-okay there. We can have that at the root of our application. And here's an important distinction

that's going to ask us to configure our import alias. Their default is using the @ character. The Inertia starter kit uses a tilde instead.

So we'll overwrite this instead of using the @ character with tilde/components there. Same thing here for utilities, tilde/ and we can put that at lib/utils,

sticking with their defaults there for everything except for the @ character. We're replacing that with a tilde. Then lastly, we'll have it go ahead and write everything that we've configured here to a components.json file. So we'll hit yes for that.

Then it's going to set all of this up for us. And once it says success, everything should be ready to go for us. So in the background here, on our side of our text editor, we should see a couple of things got added in.

First, we now have a CSS file back inside of our application with the same name that we were using originally. So we don't need to change any of our configuration there. With this, it's added the Tailwind directives

as well as set it up in a way where we use CSS variables for our colors. And these are then passed into our Tailwind configuration. And you can see it's also using layers here as well

to designate priority on certain things. We now also have a components directory. This is where it will install our shotCN components as we install them individually.

It will put them inside of a subdirectory inside of components called UI. And we also now have a lib with utilities added in. This is really just a single function of CN

that's just going to merge classes together. I'm not sure if we actually ever make use of this, but this is something that shotCN view uses internally inside of the components as well.

Okay, so we can collapse those back down, scroll down a little bit further, and we should see in addition to those two files, a components.json that just kind of holds our shotCN configuration inside of it,

specifying that we are using TypeScript, that we're using the default style, where our TS config is, the Tailwind config, what framework we're using, and the aliases there as well. And then lastly, our Tailwind config,

which has now been added. If you're using ESLint, you can go ahead and give that a save or replace all of the double quotes with single quotes. And then you can see that it sets our theme up and it extends our colors

so that we are using CSS variables for all of those. And it also adds in their animate plugin there that they use as well. So you can tell by the red squigglies here that we definitely want to change some things inside of here, but most importantly,

we're going to want to make sure that our content is updated because currently this thinks that we're working off of the root of our project, which we are not. All of our view-based stuff is going to be specifically inside of our inertia directory.

So we want to update that accordingly. We can also simplify their strings there a little bit as well. So we can do ./inertia, have this considered the pages directory,

components directory, app, and layouts directory inside of our inertia directory. And then any sub folder and any sub file

inside of those folders ending with TS, TSX, or view. And that should account for most use cases here. We can go ahead and update this to account

for our EdgeJS pages should we add any as well. So ./resources/views. ./. in any Edge file there.

Cool. And then we are using modules instead of common.js. So we just need to update our imports and our exports accordingly.

So export default there. And then instead of using require, we want to import animate from TailwindCSS animate.

There we go. And that should be all of the red squigglies that we had inside of this file. Looks good. So let's install a test by installing our first component. Now, if you are using Visual Studio Code,

there is a plugin that we can use to make this easier. So we can search shodcn-view. And you should see this right here by Selman Dev.

And give that an install. And what this will allow us to do is use the command palette to install components as needed. So if we hide both these files away

and let's do command shift P, type in shodcn/view, you should see all of the applicable commands this plugin has added. We can add a new component. We can add multiple components,

open a documentation and reload the components list there. What we want to do right now is install our first component. So we will click on install new components. And let's just search for a button

as that's a typical use case there. What that's going to do is it's going to run npx shodcn-view at latest, add button to install that inside of our project for us. So once that's run,

we can go ahead and close out that terminal altogether. And now if we look inside of our inertia components UI directory, we should see a UI and a button directory within there

that has our shodcn button as well as an index file inside of there. So it has successfully installed our button. What we can do is jump inside of our page, go inside of our home.view page.

This is the page that's rendered out whenever we boot our application and open it up inside of the browser. And let's just drop a button on here. So we can do import. This is not an export default, but rather a named export.

So we'll import button from tilde to use our alias/components/ui/button. And that index file inside of the button directory that we saw

just allows us to reach directly for the button directory as a whole rather than a specific file inside of there. So now we can make use of our button by doing button.

And we can just do example button for the actual text. Give that a save. Let's jump back inside of our terminal, clear that out and npm run dev to boot everything back up.

We can command click on our server address to open it back up. And there we go. Our example button looks like a shotcn button as it's supposed to. So everything there is working a-okay.

Furthermore, all of the initial styles that we had saw whenever we booted our application up initially are now gone because our app.css file has been deleted and overwritten. Cool. So last thing to take care of here

that I promised at the beginning of this lesson is automatic imports so that we don't have to add that button import or any other imports for the components that we have installed as we're working on things. So let's hide that back away.

Stop our server here for a moment, clear that out. And let's do npm i -D to install this as a dev dependency.

Unplugin -view -components. Let's install that. And this is the package that's going to allow us to automatically import components

without actually having to write the import ourselves. It will detect that we're making use of the component and register it inside of a file that will then be used whenever we build our final assets.

So that installed successfully, we can go and clear that out, jump back into our text editor and specifically go down to our V configuration because we need to wire this up.

We can import the components plugin from unplugin -view -components and we want to use specifically their V component plugin.

So with that defined, what we want to do is add that to our V configuration plugins. So underneath our AdonisJS plugin here, we can add components, call this as a function

and provide it in some options. First, what we're going to want to do is tell it which directories to look for. We only have a single directory here, which is our inertia components directory. We want to have everything inside of there

we want it to consider so that as we make use of it inside of our pages or even other components, it will map those imports automatically for us so that we don't need to make them manually. Then since we are using TypeScript

and we are using Visual Studio Code, which supports this configuration option, we'll specify DTS and set that to true. This DTS option tells the unplugin -view -components

that we want to generate out a TypeScript friendly configuration of our component mappings, which essentially is going to add TypeScript support to these automatic imports for us.

This may or may not work with your text editor. It does work with Visual Studio Code, so we are okay here to go ahead and use it. With that defined, let's go ahead and jump inside of our home page again,

and let's just remove the import altogether. With that import gone, we're still going to make use of our button, but now that unplugin -view -components plugin is going to automatically detect that we're making use of a button component,

map that back to the actual component that we have inside of our components directory and automatically register it for us whenever we start our server. So let's jump back into our terminal,

npm run dev to start our server, and whenever we did that, you should see that a components.d.ts got added to the root of our project. If we open this up real quick, you'll see that it detected that we're making use of our button

and it registered an import for it. So if we open our browser back up, you see our page just refreshed there and we still see our button. Let's do a sanity hard refresh here as well, and we still see our button.

So everything there is working a-okay. So we now have tailwind configured, shotscm-view configured, and automatic imports from our components directory configured as well.

Now, one thing you may have noticed is that the components that we actually import within our script, so for example, we're importing the head component from inertia-js-view-3 here. Those components are purple, at least within my theme,

whereas the ones using the automatic component import from unplug-in-view-components are the same color as any traditional HTML element, for example, our button here.

And the reason for that is because TypeScript is not aware of these. For example, our automatically imported button is currently a type of unknown, which means that if we needed to use this button

as a ref inside of our script, it wouldn't know what type to automatically map that to. Now, I'm circling back at the end of this series and adding this in, so the rest of the series, we're gonna make use of components

just as they are right here. But if you would like for your components to have types automatically associated with them, even being automatically imported with unplug-in-view-components,

then we can easily do that by registering our components.d.ts file, which is the file that maps all of those components to their actual location

inside of our inertia-files-ts-config.json. And what we wanna do is map to that components.d.ts file from the include array.

So we need to go back a directory so that we're back inside of the root folder and then map to our components.d.ts if you would like TypeScript support for those automatically imported components.

So with that said, if we jump back into our home.view, you'll notice that my button is now purple in association with my theme, noting that the type of this button

is now this really long VLS with template slots, defined component VLS with defaults, so on and so forth, just mapping it back through the imports to its actual type.

Again, as noted, I'm not using this throughout the rest of the series, but if you are, you may notice some mismatched types as we progress, for example, things that I provide as a number

that are meant to be a string or vice versa for their prop values. But things will still work A-okay for you. You may just need to appropriately adjust types as needed there.