Of course, as our projects grow, the folder structure for our projects become, I don't want to say more complex, because that's not necessarily the right word, but it becomes definitely more involved, especially wherever we store our JavaScript. Because if we're using Vite, then chances are we are using Vue or React or something else that revolves around components, which means that we would have a components folder, but then we would break that down into individual folders for individual parts of the application. Like, for example, if we have a login component, that might be inside of an auth folder or something like that. But then we could have a folder called shared, because there are always those components that we would share across multiple parts of the application, something like a modal.

But then we could have a folder called shared, because there are always those components that we would share across multiple parts of the application, something like a modal. So let's just create that file, let's export, default, and a modal needs to be able to show something. But let's just write a message to the console to do implement show. But of course to import this, that means that inside of App.js or wherever we wanted to use this, we would then need to import modal from, and then that would be components/shared/modal, so that then finally we can call that show method. And that's going to work just fine, but of course we have so many other files, so many deeper folder structures that we would have to work with, paths become an issue.

And that's going to work just fine, but of course we have so many other files, so many deeper folder structures that we would have to work with, paths become an issue. And then since we are building a single page application, the documentation recommends to not use a CSS entry point. So really what we would need to do is comment out that CSS entry point so that we could then import that through JavaScript, which means, hooray, we have another path. We have to go back to resources, and then CSS, then finally app.css. Let's change our welcome view so that we are no longer pulling in that CSS file. And if we look at the browser, everything looks the same, and

Let's change our welcome view so that we are no longer pulling in that CSS file. And if we look at the browser, everything looks the same, and we have that to-do message inside the console. So everything is working okay, but I want to tame these paths, because it's only going to get worse from here. Now, Vite has a feature called aliases. It basically allows us to define a symbol or a string, and it will translate that string into a path that we specify. Now, it's only usable inside of an import statement, but it can be very useful. And the Laravel plugin gives us a default alias of an at sign.

Now, it's only usable inside of an import statement, but it can be very useful. And the Laravel plugin gives us a default alias of an at sign. It simply points to resources/js. So in the case of bootstrap, we could say @/bootstrap. For the modal, we could say @/components/shared/modal. Doesn't really gain us anything in this particular case, but that's the typical idea. But two, we can also override that, and we can define a different path for that alias. All we have to do is go to our vite.config.js and add a resolve object.

we can define a different path for that alias. All we have to do is go to our vite.config.js and add a resolve object. Now, this is outside of the plugins, so just keep that in mind. Don't put this inside of the plugins array, because it's not going to work. So inside of this resolve object, we have an alias object. And then here, we can define the alias in two ways. Probably the most straightforward thing is to just have an @ sign or whatever we want to use as an alias, and then the path. So if we wanted to say that the @ sign goes to resources/js/components, we can do that.

So if we wanted to say that the at sign goes to resources/js, and then components, we can do that. So that we can change at least the importation of our modal here, so that we could say @/shared/modal. And that doesn't, well, yes, that doesn't work because we changed the path of that alias. But now we can see that we get the same result as we did before, and our modals show method is executing as it should. But I don't necessarily want to override the default alias here. So this means that we can define our own aliases.

But I don't necessarily want to override the default alias here. So this means that we can define our own aliases. So for example, we could have a components, but really that doesn't gain us anything. We can say comps. Yeah, let's do that. So that will point to resources/js/components, so that our import statement for that could be at comps, which is a little bit shorter. But we could also create an alias for our CSS, so that it would look like this. We could say at CSS, and that would go to resources/CSS.

But we could also create an alias for our CSS, so that it would look like this. We could say @css, and that would go to resources/css. So now we can change that import statement to just be @css. And if we look at the browser, we can see everything is working as it did before. And one of the really cool things about aliases is that these aliases can be anything. I have used the @ sign just because, well, that kind of makes sense. Our aliases begin with an @ sign, alias @. I mean, I get it. But if we wanted to, we could completely omit that.

I mean, I get it. But if we wanted to, we could completely omit that. But then our paths look like this. And then we have to question, okay, is this an alias? Is this a folder? What is that? So I'd say, of course, it's important to be consistent with however you define your aliases, but use something that appears to be obvious. So if you don't want to use an at sign, don't use an at sign. But just use something to denote this is an alias.

So if you don't want to use an at sign, don't use an at sign. But just use something to denote this is an alias. Now, we can also define aliases with a slightly different syntax. Instead of alias being an object, it can be an array. And then each element in the array would be an object that has a property called find, which would be the alias, so that would be CSS. And then a replacement property, which would be the path. So here we would have resources and then CSS. We would then have another object, findAtComps, and the replacement there is resources.js.components.

We would then have another object, findAtComps, and the replacement there is resources.js.components. So either way, we are going to end up with two aliases. But I personally like the other syntax just because it is much more concise. But I'm gonna do this. Let's comment this out so that we have both of these inside of our config file. Now, one very important thing to note is that these aliases are for our import statements. This isn't something that we can just use in any string.

our import statements. This isn't something that we can just use in any string. So inside of our modal, if we change this to CSS, we are going to see this exact string inside of the console. So these aliases work only for importing assets and nothing else. So you don't have to worry about paths really ever again. Create an alias and your life will be so much easier.