DEV Community

Jason
Jason

Posted on

Double Depping: Use import maps and deps.ts together

Import Maps !== Deno Dependency Management

Import maps serve as an import alias and not necessarily as a manifest for
dependencies.

Import map keys are to add some sex-appeal: shortcuts, aliases, mirror/redirect URLs, client-side usage, scopes, file system paths, so on and etc.

{
  "imports": {
    "@/", "./where-its-at",
  }
}
Enter fullscreen mode Exit fullscreen mode

deps.ts: Just a Typical Script

The practice of using deps.ts is for adding logic. This script's primary
purpose is to export your modules and types together from external
dependencies and local libraries.

It's a bit like putting ./node_modules and module.exports together. Mix that
with modern export declarations, and –🎉– the real beauty and purpose of Deno becomes more apparent.

Package and Lock

Use these two files in tandem to manage dependency versions. Whether you want to set your version numbers in the deps.ts or import_maps.json file is up to you. It could even be irrelevant, depending upon the dependency usage. A single-use helper function, for example, does not need to be updated alongside its parent module.

Is this Bad for Bundles?

The article Why deps.ts is Bad in Deno points out that the practice of using deps.ts prevents tree-shaking; however, Deno's Bundler output is intended for consumption in Deno.

But it Slows Down Compilation

bUt It sLoWs DoWn CoMpiL— Who cares? Its compilation time is negligible when your project is hosted by servers powerful enough for edge computing, like Deno Deploy, Netlify and GitHub Actions. Your local development process can be sped up by utilizing Deno's built-in tools like deno test and deno info.

Independence

This mix-and-match method of composing dependencies may seem haphazard, but Deno's compiler does not mind.

You do you. The best practice is whatever feels right for your project. Create your own convention with collaborators. Or don't, because it doesn't matter for a random, one-time sandbox repository without much code review.

Or do, because you can be opinionated and unconventional. Your method could lead by example, or you can find many great examples to follow.

OSS FTW!

TLDR

Ryan Dahl explained this in the 10 Things I Regret About Node.js presentation...probably. (I don't know. It was too long. I didn't watch it.)

Top comments (0)