Deno First Look

Remote Dependencies

Burke Holland

Burke Holland

Deno First Look

Check out a free preview of the full Deno First Look course

The "Remote Dependencies" Lesson is part of the full, Deno First Look course featured in this preview video. Here's what you'd learn in this lesson:

Burke explains Deno's list of approved remote dependencies and live codes importing a remote dependency by URL. How to import a remote dependency without URLs throughout the project is also covered in this segment.


Transcript from the "Remote Dependencies" Lesson

>> All right? So that's how local dependencies are handled. But remote dependencies are handled a little bit differently. So, remote dependencies are what we would today called a call npm packages and these are the things that you would install from npm. It's code that you consume that someone else's written.

Deno has a list of approved third party modules. So, It's sort of starting to create its own centralized set of libraries here, kind of like npm all over again. But you can see something like lodash is in here. Let's see which one do we wanna use up? So there's a path module.

So let's look at that. In Node if we wanted to get the path for something, so let's say we have, let's just do this. Actually, we can just do it in our app file here. So let's close this out. We don't want to reverse the string anymore. In Node we can do const path = require path.

And then you can do something like this console.log(path.basename. And then if you did in a folder/ folder/ folder/ file.txt. What this returns is, if you ran this, what it would return is file.txt. That's the base name. So Deno doesn't have a path and so we have to import a dependency to do that.

And so we're gonna import Deno standard library to actually see how Deno does this. So Deno's standard library is here. Let's go back to Third Party Modules. So if we go to Standard Library. So this is the standard library here. You can see all of the things that are in its standard library.

Like datetime, and the fs module. All the stuff that you would normally see with Node. It mimics the node API really, really well. So let's look at how we would do that. What we need to do is import it by URL. So we're gonna do that here. So let's just grab this, and then go back and see what happens when we try to do this.

So we're just gonna import this thing by URL. And you can see that Visual Studio code is actually fine with this because I've imported this before. If you don't wanna specify the version of the file, you can take this out and it will just give you the latest version, which I've already got here.

And if we were to click on this, it would take us to the actual file on my local machine where this is already cached. But now that we've got this we can do path.basename. So let's run this again. So let's do deno run app.ts, can't you, exercise app.ts?

You know what I did, we're in the cache directory again. So let's swap out of that. And in fact, just for fun, let's do this. Let's clear the cache. So let's clear let's go to deps. rm -rf https. Cool. That's gone. So now let's reload the Window. Cuz I wanna show you what Deno does here when it doesn't recognize your dependencies.

So it should,yeah so see it's got a squiggly and it's like I don't know what this is. Could not find module this mod.ts locally, by the way, this mod, you're gonna see this a lot in Deno this is just a standard short for module. That's all it is.

But it threw me off when I first saw it. Okay, so if we do control period here in VS code, it says do you want me to fetch the module we're gonna say yeah, so it's going to fetch it and bring it down and stick it in that cache folder.

Then now we can use it, right? And so we have if we do path, then we have all of the different things that are on this. And so we can run this. Let's run it. Nope. Again, in the cache directory. Try that again. Exercise. Let's run this and it'll give us.

Hopefully, yeah, file.txt. And so this is how dependencies are included in Deno projects is by this URL and then it gets copied down to your cache directory and then it just kind of hangs out there. And then unless you actually change the version or import it again, it forced the cache to update and it doesn't actually change.

But we know that Deno doesn't actually download dependencies every single time we run the program. It just does it the first time. And then it downloads it to that depth cache and then it stays there. If we were to take a look like let's say, let's do I don't know.

Let's see, I'm trying to figure out, what did I have you do in the exercise? We're looking at, Yeah, if we were to use something like the https server, that would Wind up in a different folder here. And there are a lot of different files that we could get inside of that folder as it grows, we have more and more dependencies.

We can get actually more info about like the dependencies that this specific path module has. If we just run deno info. Now we could run deno info on this file here directly. We could actually do this. We wanted to know some more about it. I think we can just do, no, let me do deno info.

Just paste this in. Yeah. And then we get a dependency graph that shows us all of the different things. So when we use path and we're in path, and it's gonna bring in all this stuff as well, path depends on util. It depends on common which depends on separator, which depends on OS, and so on and so forth.

And so this is how you can examine the dependencies that you've got. And if we were to go to that deno cache folder, you would see all of these different files in there. Now, I wanna take a moment and address sort of the elephant in the room or what I frequently hear people say, which is that importing from URLs feels like completely nuts and insane.

And I wanna validate that but say that we've already established the Deno wants to stay as close to browser conventions as possible. And in that case, importing from a URL should feel less achy because that's just how we do it. But it isn't very pleasant to look at, right?

Let's just be honest. Okay, seeing this in code just doesn't feel great. Having a URL here. I mean, really, we're gonna write code and have URLs just hanging out all over in our imports. That doesn't sound great. So what Deno recommends that you do is they recommend that you create a file inside of your project that you call depths.ts.

So let's do that depths.ts. So again, this is just a convention, right. This is nothing special. And then you would take all of your URL imports here. And you would stick them inside of this and then you would export from this file what you needed so export, here we're just going to export path.

And then in our app.ts file instead of importing path, we would do import path from depths.ts. And so all of the URL weirdness is sort of hidden away in this depths file and it doesn't leak all over into your projects because I don't think you would want that.

And we'll see later on, we're gonna use a lot more dependencies. You'll see how this it makes it look cleaner.

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