loading...

Do we really need a package manager for deno?

buttercubz profile image Erick Sosa Garcia Updated on ・2 min read

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.

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.

// 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 a proposal for the web that deno already implements but for now is an unstable feature.

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

this allows importing in a much more traditional way

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 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:

$ npm install lowdash

Trex in deno:

$ 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:

$ 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.

Posted on by:

buttercubz profile

Erick Sosa Garcia

@buttercubz

Hello I'm Erick I study Javascript, typescript, python, go, Node js and focused in deno πŸ¦• Creator of Trex package manager https://deno.land/x/trex

Discussion

markdown guide
 

Deno, itself, doesn't need a package manager, but the JavaScript community benefits greatly by having a community-driven effort to curate and do security audits on packages. Also, it is ideal to only have links to a few known domains for routing/firewall whitelisting, rather than many independent repositories.

In the future, it is possible that package validation services from GitHub and GitLab could be a replacement for NPM/Yarn. Personally, I feel that NPM/Yarn are so integral to the Node JS experience that Deno will, eventually, need to match them to promote adoption.

 

I agree, but although companies like npm / yarn review the packages, it does not mean that they are safe and in cases like Event-Stream They demonstrate that malicious code can be injected, the community is very attentive and detects this type of insertion, but it is a much bigger problem that does not depend on the execution environments, but on how we depend on third-party software.

 

Maybe not really a package manager, but I think that its nice to have a single place to specify the repository path/mapping and the version. Like we have in the mappings, but if we use it for everything then it's a package manager :)

I am thinking more in a case that you need to bump a minor version because of a security problem, and the list of changes... And what happens when you mix different versions through the files by mistake :)

 

I think we don't need a package manager for deno but one with which to manage dependencies.

 

Iv been working bundlless with snowpack lately, no you don't need a package manager. I think a snowpack frontend would work fantastically with Deno!