Steve Kinney

Steve Kinney


Check out a free preview of the full Vite course

The "import.meta" Lesson is part of the full, Vite course featured in this preview video. Here's what you'd learn in this lesson:

Steve discusses how import.meta can be used to access environment variables and provides examples of how to use them in development and production environments. They also demonstrate how to add environment files and customize environment variables in Vite. Additionally, they address how to handle import.meta in TypeScript and provide a solution for accessing environment variables in a TypeScript project.


Transcript from the "import.meta" Lesson

>> Right, so that's a great segue into talking a little bit more about some of the other things that are on import. And one of the best ways to figure out what else is on import is just to do everyone's favorite thing, which is just console.log things. I understand there's a whole bunch of tools out there, but you know which one I like?

I like me some console log. So we have import meta, import meta this part of it is definitely part of web standard. If you are in like node using ES modules, you can do import meta.url that is a standard like what they is the current URL of the file.

But if we look at importmeta in our tooling real quick, in our console, so you've got that URL. And then you've also got vdadsin.env. And you can see that it'll actually show you some environment variables in this case. And what's important to note is that in development, sure, yeah, these are whatever the current environment is in production.

It is whatever the environment was when you built the app, right, because you're building static assets that don't have access to any of this anymore. But you can kind of see some, I think some of the more useful ones are up this dev, right, am I in development or not?

If I show you, here I'll show you real quick, and we'll talk a little bit more about this when we look at some plugins. But if I go to my local version of the course website, I am very lazy. And I made myself this open in Visual Studio Code, so it'll open Visual Studio Code in the Markdown file I'm looking at right now that's on my file system.

And I'll show you the plugin a little bit if you really want to see it, but that's using that like, okay, if you know import.meta.env, if I'm in dev mode, show me this, otherwise, this doesn't mean anything right to somebody who sees it on the production website. So it's like things that I only show in development, and this could be all sorts of things, like if you wanted to have some kind of way to load different state into your store, like in Redux or whatever, when you're in development.

You could have like certain things that you show, or like mock out the API only in development, so on and so forth, using like mock service worker or something like that. The dev and prod flags are super useful. If we go back, we can see the base URL, like, yeah, I could change that to have a subdirectory, whether or not we're using server side rendering for that page, so on and so forth.

The mode, right now is development. If I were to go to, it would be build in the case of build So on and so forth. And we can actually add more things in here, as well, by adding environment files. And so environment files are a way to basically have other environment variables.

And there's some rules, because it's not just going to take any environment variable in your machine. That would be bad, right? Because that's everything even at build time. What OS are you running? And if you do process at env and node you can see it's a giant file of stuff you probably are not super interested in shipping in your client side code, right?

And so you notice that even in that environment, there's not a lot in there, but I can make a new file. I can say .env, and in here, I can put an environment variable, and you're gonna see it not happen. You won't see me equals hi, and as you can guess, what happens is you will not see it because out of the box, V will only include ones that have the prefix VT, can you change this?

Of course you can change it, right? But it does make you like have to, like opt in to allow listing an environment variable, right? So now you can see that it's definitely in place there. One of the things that I learned the hard way If you look in the part that I wrote about this, I think it's in this now it's in this other section over here.

I wrote import.meta.env. Because it will actually even replace any of those values in your HTML as well [LAUGH] I was like, why do I have this big JavaScript object in here? And I went to like 'cause it made the formatting all weird and went to go like search where I'm like I didn't write all that, that's why I had to escape it a little bit.

But it will actually, it can even interpolate those values in your HTML as well. But yeah, so you can ask if you just have to put this VT like you won't see me and then like anything while you will see me now, right? Like, it's now a lie that I prefixed it with VT.

And so to have a variable that's available in your client side code, it doesn't need to be prefixed with V in this case, but like, you can change it, I just don't, I will use VT and Rs. You can make an app. You can make it whatever you want.

And the other thing that you can do is this environment .env will be loaded in all environments, right? You can do for different modes. So, for instance .env, .local, right? For instance, will only be loaded doing local development, right? So this is the mock data. If you have a different endpoint in development than you do in production, you might have a different setup here as well, right?

And so here I can go. Right, and this could be a different database, name and password and URL in this case and you will see all that. So now if I want to go build this, that one would not appear in the build because it's only in local development, right?

And so you have ones that you can do for production, you have ones you can do for local, and you can set the environment variables as you want. And these are added in by Vite in this case. And so we have it set up for different endpoints. Like, locally, yeah, we have a server running localhost 3000, in production it's got a fully qualified domain name, so on and so forth.

You can set all these things, and you basically kind of get it for free, and it's like reading these files as you go through, right? And like I said, if you don't put the prefix, you don't get it. So that's the only, like, kind of tasty note that you need to kind of keep in mind in this case.

>> To import dotnet, it doesn't seem to work with TS config. If we're setting up a proxy, how do we get the environment variable?
>> That's a good question. Okay, so if you are using, let's go ahead and let's make a new file in here. And let's watch TypeScript get angry with us, right?

We'll say angry.ts, right, and let's say we want to do console.log. What is it? import.meta.env, right? It's very upset with us, right? Because import, that's a web standard. Import.meta, that's a web standard. Import.meta.url, that's a web standard. Import.meta.env, that's a Vite-specific thing, right? And so he's like, now what?

All that you need to do is have somewhere, right, like. I you'll, you'll see this in the, if you choose TypeScript, you'll probably actually even see this in that template that we did with React and TypeScript as well. There's some kind of any, it doesn't have to be vite.d.ts.

It could be any, any one of your declaration files. Yeah, there's reference types, vite/client. If you put this in, like, this is going to say, you can actually refer to it in your TS config too, but it's going to say, hey, vite, pull in all the types that you know about from like the you're adding in for all the stuff that you're doing.

So now if let's go grab this and bring it back over to the other project and now if we look@angry.ts. It's totally happy with the env because we're basically, VT has stepped in and added all of its types and declared them on the modules for everything that it's adding into the scene.

So if you are, other than changing the.ts if you're using vi-specific stuff, all you need is a d.ts file with a reference to the client types for vite. And you will then get all those types for free. Awesome, and so but then what about we're not out of the woods yet, we're not out of the woods.

So let's do, I don't know what happens over there all time, import.meta.env, what was it? VITE, you won't see me or you will see me That one gets marked as any, it works because vite's like they're probably putting stuff on this environment. So it works but no one feels good about this, right?

And so in this case, if you are going to define your own, now they are all going to be strings, but we don't know if this one exists or not. I would really like to like know. So I'll kind of show you. I actually like, for this purpose, I grabbed the one from my own app.

I'll just kind of show you because we don't use a ton of these variables. I'll just kind of show you the one that I use in our app, which is you can basically take that interface because if you looked back over here is that import.meta M, that's what's vite's adding to the equation.

What I can do is then for the ones that I know that we have, so like we have a cloud product, we have an open-source product, they have slightly different APIs of the servers that we talk to. And so I can theoretically have conditions. Okay, if we're targeting our cloud product, hit this endpoint, if we're targeting the open source, do this other thing, right?

And then at build time, those will get actually compressed into, whatever the build target was. And I don't have to think about it. So I can build two different versions of the app. So I just, defined as a read only string in my application, but for the most part That's all I'm really adding in there.

And I'm adding all of whether or not we're in Vitest. I practice saying Vite a lot. I did not practice saying Vitest. And now I'm scared to watch the Enterprise UI workshop because do I just call it Vitest the entire time? I have to write, right, because I didn't even think to practice that, in that case.

Vitest, right? We were growing as people were becoming better. We're learning, we're pronouncing things right. And so I can like pull in those as well. And then yeah, so if using TypeScript and you need the types around this stuff, super easy to add, you add this you get most of the types for any of your custom stuff.

You can basically just add those classes on there as well. And you will get it and have everything there as well. So that was a great question with great timing. And there's not like a lot like environment variables or environment versus you know, the ones that you need, right, based on your app.

They're a little bit different for everyone. Most of you are probably not building something different for an open-source product versus a cloud product, but you might have development. Because the thing about working on an open-source server is I can run my own product, localhost, the real deal, but for most people that's not true, right?

So you might have your SQLite database or your mock API or something like that, only use mock service worker, which is something for mocking out APIs, client-side, if we're in development otherwise, fall through to the regular app. Those are all options, but those are all very, what you need will depend on your setup, but the way that you solve it, is always gonna be the same, which is to define whatever environment barrels you need for that information.

You can pull them in as you need them, and everything's gonna be great.

Learn Straight from the Experts Who Shape the Modern Web

  • In-depth Courses
  • Industry Leading Experts
  • Learning Paths
  • Live Interactive Workshops
Get Unlimited Access Now