Do we really need a package manager for deno?
Tags: deno, node, typescript, javascript
Published: 2020-06-21 22:34:00

When I heard about deno in 2019 I thought, why another runtime for javascript?

it has some problems in its internal architecture as ryan explains in [this lecture.](https://www.youtube.com/watch?v=M3BM9TB-8yA)

A very common question about deno is where is the package manager? ryan in his lecture explains nodejs problems with npm and that trying to fix it is no longer feasible, so deno is intended to solve these problems without needing to use a package manager but changing the paradigm for some developers is not negotiable.

using urls to handle packages is used by other programming languages ​​like go, the hard part is having to handle URLs in say 30 files. one solution is to have a file where all the modules are imported like this.

``` javascript
// deps.ts

export { equal } from "https://deno.land/std@0.58.0/bytes/mod.ts";
export { Sha1 } from "https://deno.land/std@0.58.0/hash/sha1.ts";
export { HmacSha256 } from "https://deno.land/std@0.58.0/hash/sha256.ts";
export {
  serve,
  serveTLS,
} from "https://deno.land/std@0.58.0/http/server.ts";
export {
  Status,
  STATUS_TEXT,
} from "https://deno.land/std@0.58.0/http/http_status.ts";
export { BufReader, BufWriter } from "https://deno.land/std@0.58.0/io/bufio.ts";
export { copyBytes } from "https://deno.land/std@0.58.0/io/util.ts";
export {
  basename,
  extname,
  join,
  isAbsolute,
  normalize,
  parse,
  resolve,
  sep,
} from "https://deno.land/std@0.58.0/path/mod.ts";
export { assert } from "https://deno.land/std@0.58.0/testing/asserts.ts";
export {
  acceptable,
  acceptWebSocket,
  WebSocket,
} from "https://deno.land/std@0.58.0/ws/mod.ts";

// 3rd party dependencies

export {
  contentType,
  extension,
  lookup,
} from "https://deno.land/x/media_types@v2.3.7/mod.ts";
export {
  compile,
  Key,
  parse as pathParse,
  ParseOptions,
  pathToRegexp,
  TokensToRegexpOptions,
} from "https://raw.githubusercontent.com/pillarjs/path-to-regexp/v6.1.0/src/index.ts";
```

another way is using [import map](https://deno.land/manual/linking_to_external_code/import_maps) a proposal for the web that deno already implements but for now is an unstable feature.

``` json
// import_map.json
{
   "imports": {
      "fmt/": "https://deno.land/std@0.55.0/fmt/"
   }
}
```

this allows importing in a much more traditional way

``` javascript
import { red } from "fmt/colors.ts";

console.log(red("hello world"));
```

but we can have a way to handle modules like with npm but without dragging the problems that npm has. [Trex](https://github.com/crewdevio/Trex) is a project that I am developing that tries to implement the best of both sides, It combines the way to install modules using a cli but without the node_modules folder since everything is cached, the ability to install tools like velociraptor and denon in a very simple way.

Trex just creates an import_map.json file where all the dependencies are listed.


npm in node js:
```sh
$ npm install lowdash
```

Trex in deno:
```sh
$ trex install --map oak
```
all modules are extracted from the deno website, so any modules that are in the standard library and in `deno.land/x` can be installed with Trex.

You can also install a custom module from anywhere using:

```sh
$ trex --custom React=https://unpkg.com/react-dom@16/umd/react-dom.development.js
```

likewise it is added to the import map and the cache.