Linking to third party code

test.ts

Try running this:

Note that we did not have to provide the flag for this program, and yet it accessed the network. The runtime has special access to download imports and cache them to disk.

Deno caches remote imports in a special directory specified by the DENO_DIR environment variable. It defaults to the system’s cache directory if DENO_DIR is not specified. The next time you run the program, no downloads will be made. If the program hasn’t changed, it won’t be recompiled either. The default directory is:

• On Windows: %LOCALAPPDATA%/deno ( = FOLDERID_LocalAppData)
• On macOS: $HOME/Library/Caches/deno

The solution is to import and re-export your external libraries in a central deps.ts file (which serves the same purpose as Node’s file). For example, let’s say you were using the above assertion library across a large project. Rather than importing "https://deno.land/std@$STD_VERSION/testing/asserts.ts" everywhere, you could create a deps.ts file that exports the third-party code:

deps.ts

ts, ignore import { assertEquals, runTests, test } from "./deps.ts";

This design circumvents a plethora of complexity spawned by package management software, centralized code repositories, and superfluous file formats.

By using a lock file (with the --lock command line flag), you can ensure that the code pulled from a URL is the same as it was during initial development. You can learn more about this here.

This, like the above, is a problem faced by any remote dependency system. Relying on external servers is convenient for development but brittle in production. Production software should always vendor its dependencies. In Node this is done by checking into source control. In Deno this is done by using the subcommand.