Thinking like a browser
You'll remember from the earlier introduction section that Deno thinks differently about dependencies. It's a core design premise. But we didn't talk about how it's different.
Deno works the same way. You require in dependencies by URL. If you are requiring a local dependency, it's just the relative path. If you are using a third-party library, you do it by the URL.
Deno follows the ECMAScript standard for
Caching is an important part of how Deno handles dependencies. Since it uses the URL reference as the method to include them, you wouldn't want it to try and download those every time you ran the program.
Instead, Deno downloads a dependency the first time that you run the program and until the dependency changes or you force an update, that cache is where the dependency is served from.
How Deno handles dependencies is different based on whether or not you are using a local dependency (importing a file in the current project) or a remote dependency (referencing a third-party module by URL). In the next few sections, we'll look at how Deno handles these two scenarios, and some best practices for organizing dependencies in Deno.
As we move through the next sections, the
deno info command may come in handy. By itself, the command returns the location of your Deno cache. Try it out and see what you get...
Here's what I get...
DENO_DIR location: "/home/burkeholland/.cache/deno" Remote modules cache: "/home/burkeholland/.cache/deno/deps" TypeScript compiler cache: "/home/burkeholland/.cache/deno/gen"
We'll be looking at these directories going forward. If you get stuck or can't find the cache, a simple
deno info should get you there.