Since the release of Deno 1.0, those developers who have not been able to learn have been honest enough to at least hit Brew Install Deno to show their presence. When you run out of the first Deno app following the official example, you can see that this little dinosaur is very ambitious and promising.

Let’s take a look at the official example:

deno run https://deno.land/std/examples/welcome.ts
Copy the code

Clean and concise, it’s a little exciting to think that JavaScript/TypeScript is one step closer to dominating the world.

But what does this have to do with me writing about the server? Hence the official second example:

import { serve } from "https://deno.land/[email protected]/http/server.ts";
const s = serve({ port: 8000 });
console.log("http://localhost:8000/");
for await (const req of s) {
  req.respond({ body: "Hello World\n" });
}
Copy the code

Hey! Qi to live! It seems that Deno is already a runable program that can be considered for production use. However, the beginning of kinesis is the beginning of nightmares……

Enter the theme

Let’s take a look at how Deno introduces module dependencies:

import { serve } from "https://deno.land/[email protected]/http/server.ts";
Copy the code

As you can see, the import source, package name, version number, and module name are all tucked into the URL. What a clever trick! As long as my scripts are online, I can run anyway. Instead of putting a node_modules black hole in each project, Deno’s global unified cache can be used to remotely import modules. Also save a lot of disk space, really sweet!

(Note: the hole itself is not so deep after NPM 5.0)

Is there anything weird about the excitement? Yes, this dependency approach is very similar to the way you introduced jQuery directly into HTML in the early years. The semantics are clear but extremely verbose, and instantly doubt life. Is Deno going backwards in time?

Yes and no, more on that later.

When the project is very small, the introduction of absolute URL can help you start a project quickly, but when the project scale gradually expands, the directory structure becomes complex, and the number of development collaborators increases, dependency management becomes imperative.

So how does Deno manage project dependencies right now? Linking to External code: Create a central deps.ts file, import and export the module you need, and import from deps.ts in other files. The code is as follows:

// deps.ts
export {
  assert,
  assertEquals,
  assertStrContains,
} from "https://deno.land/std/testing/asserts.ts";
Copy the code
import { assertEquals, runTests, test } from "./deps.ts";
Copy the code

In response, I:?? Is that your little dinosaur management plan? Apparently they don’t want us to embrace Deno development! It can be expected that maintaining a copy of DEDs.ts would be a disaster for any project of any size to manage dependencies in this way, and if you think about it, it doesn’t fit the ES Modules semantics you preach. For a practical example, If I needed to add a method createSign to the import code, I would have to modify both files at the same time:

// deps.ts
export {
  assert,
  assertEquals,
  assertStrContains,
  createSign,
} from "https://deno.land/std/testing/asserts.ts";
Copy the code
import { assertEquals, runTests, test, createSign } from "./deps.ts";
Copy the code

This is too bad! It is not only tedious and error-prone, but also very unclear to introduce the source module name, and even need to use as to deal with the possible namespace duplication problem, which is a big head. The actual development experience never and NPM uses an assortment like import {assertEquals, createSign} from “implies”, discard the results! In the end)

Don’t go! Let’s take a look at Deno’s dependency management and see if it can be saved. After all, 1.0 was only released two weeks ago, so it’s not perfect yet.

Initial diagnosis

First, let’s list the design advantages of Deno in module management:

  • Supports direct import from the remote end
  • Use ES Modules specification
  • File-oriented import
  • There is no node_modules
  • decentralized

To list the disadvantages:

  • Absolute path ponderousness

  • Manual management is cumbersome and error-prone

  • Loose version control

  • decentralized

    (You read that right. Decentralization is both a strength and a weakness. I will elaborate on my views on decentralization at the end of this article.)

Suit the remedy to the case

The strategy is simple: fix the flaws without destroying the good.

1. Delete absolute paths

Import Maps supported by Deno is an effective solution to eliminating bloated absolute paths. Create an import_map.json file that describes the mapping between the module name and the referenced source URL, so that you can reference the module name directory as needed, as follows: import_map.json

// import_map.json
{
   "imports": {
      "http/": "https://deno.land/std/http/"}}Copy the code
import { serve } from "http/server.ts";
Copy the code

Nice! This is what ES Modules should look like.

2. Instrumental management

You can deny the hegemony of NPM, but the CLI management of project dependencies such as NPM or YARN needs to be supported. Otherwise, maven, Gradle, POD, and PIP should all be taken out and shot, and Go will not turn around in the middle of the kill.

For Deno, with its built-in module download cache and compiler, you only need to provide a lightweight CLI to manage dependency reference sources, versions, module request permissions (a separate article will cover that at some point) and automatically generate Import maps.

3. Add the version lock

The flexible introduction of Deno modules, coupled with loose version control, even STD (Standard Library) supports direct import from Master by default, which poses the biggest resistance to using Deno in production environments. In my opinion, proper version control is not to retrieve the version at download time and then lock it with a.lock file, but rather to lock the version at definition, avoiding any potential pitfalls.

4. Decentralization and centralization

Decentralization seems to be the general trend of the world today, and in the field of development, especially in the field of dependency management, a centralized public managed warehouse seems to have its necessity and inevitability, otherwise it is difficult to establish an ecology, also determines the development process of a development language. You may have noticed that there is a Third Party Modules section on the Deno website. Those who have contributed Deno Modules know that these Modules are currently maintained by a database.json file, which is transferred by deno.land/x when introduced. Actually connected to the corresponding Github repository in the code file, so the module mapping file is centralized, Github is also a centralized managed repository, said about decentralization? I think more in the enterprise world, building a private repository is much easier and easier with Deno’s modular design.

Get the prescription

Based on the above considerations, I wrote a dependency management tool DEP for Deno, which also provides public module hosting and CDN, which is the concrete realization of all the above considerations. Using the DEP CLI you can easily manage project dependencies or publish modules to the DEP Registry to grow the community, such as:

Add the dependent

dep add exec

# Add deno Standard Library as a dependency
dep add std:path

# Add github repO as a dependency
dep add github:acathur/store
Copy the code

Remove reliance on

dep remove exec
Copy the code

Publish modules to DEP Registry

dep publish
Copy the code

If your module itself uses DEP to manage dependencies, deP replaces all relative urls in the code with the corresponding source urls in the project Import map before packaging. This ensures that all modules published to DeP Registry can be referenced and executed without Import maps and prevents Import maps from becoming a new black hole.

For more commands, go to the Github repository deP or run deP help after installing the DEP.

Write in the last

Dep is an open source project based on the MIT License. You are welcome to report issues, pull requests or help spread the word. Dep aims to provide Deno with better dependency management solutions and promote Deno to be used in production faster. If you have better ideas on dependency management, you are welcome to discuss and practice them together.

Github: github.com/denodep/dep

Come to [manual squinting smile], don’t leave a star dear ~