Skip to content
This repository has been archived by the owner on Apr 16, 2020. It is now read-only.

Deno #49

Open
andrew opened this issue Apr 25, 2019 · 0 comments
Open

Deno #49

andrew opened this issue Apr 25, 2019 · 0 comments

Comments

@andrew
Copy link
Collaborator

andrew commented Apr 25, 2019

Deno is a new javascript/typescript runtime from the creator of node.js

One big difference between Deno and Node is the module system and package manager, or lack of one.

Deno has no manifest file (node uses package.json) or lockfile (package-lock.json), instead preferring to import third party code by directly referencing it by url, much like with a <script> tag in the browser:

import { serve } from "https://deno.land/std@v0.3.2/http/server.ts";

async function main() {
  const body = new TextEncoder().encode("Hello World\n");
  for await (const req of serve(":8000")) {
    req.respond({ body });
  }
}

main();

The initial user experience is very slick, deno automatically downloads and locally caches imported urls but from a reproducibility point of view it struggles from the same issues as Go has traditionally struggled with:

  • pointing at the tip of a master branch means every commit to that branch may result in breaking changes being pulled in without checking first.
  • urls stop working altogether stopping the running of the program altogether
  • pointing directly to a source file lacks useful metadata about the project:
    • license
    • changelog
    • a way of discovering other versions of the same package
  • man-in-the-middle attacks, with no integrity checking you can't be sure that what you just downloaded is exactly the same as before

One problem that it copies from node.js is that a dependency tree may contain multiple versions of the same library, but unlike node it doesn't have a good way to flatten the tree because the urls and version numbers are hardcoded within each dependency.

Deno does have a registry service but it currently redirects http requests to the upstream source rather than caching the result. I suspect the registry will end up heading along a similar path as the notary service being developed for the Go ecosystem.

There was an issue opened about adding IPFS support but has since been closed: denoland/deno#428

oof. Not any time soon.

I can conceive of it happening some day, years in the future. But IPFS is not very good right now. And Deno is not very good right now. We cannot dedicate time to that at this point.

Closing tho I'm open to the idea. Will be open to discussing further in 2020.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants