[Discussion]What's the best version manager for deno package?

[ahuigo]

It seems that deno has no version manager by far.
We could inject the version into our project code:

    import mod from 'mod/v0.1.1/main.ts';

It's painful as we have to write version everywhere. if we want to upgrade our package, replace the version is painful too.

So, what's the best version manager for deno package?

1. yarn's PnP solution: bind version with module, and use a resolver like .pnp.js to parse module version and module path.
2. python's solution: use requirements.txt to record package's version, use virtualenv to isolate different project(it could not isolate different version)
3. go mod solution?
4. Other solution?

[nayeemrmn]

Read the bottom section in https://deno.land/std/manual.md#linking-to-third-party-code.

[hayd]

A tool for updating versioned urls: https://github.com/hayd/deno-udd
But agree that using deps.ts makes things easier.

[jtheisen]

@nayeemrmn Link is broken.

[nayeemrmn]

https://deno.land/manual@v1.7.5/linking_to_external_code#it-seems-unwieldy-to-import-urls-everywhere

[ivawzh]

Wouldn't deps.ts make optimization (like code-split) hard?
Also, we will need to care about naming collisions, almost like global unique names for each 3rd party function.
Package source URL is forbidden to changes in the future too.

[kitsonk]

Wouldn't deps.ts make optimization (like code-split) hard?

In a server context, code splitting doesn't make a huge amount of sense. If you are writing browser code under Deno, you probably wouldn't write it like a server application anyways.

Also, we will need to care about naming collisions, almost like global unique names for each 3rd party function.

export { foo as fooBar } from "http://example.com/lib.ts"

Package source URL is forbidden to changes in the future too.

This is an argument that is "the package name can't change and the exports of a package can never change". People can choose to make a URL as immutable or mutable as they want. https://deno.land/x/ and other registries make the versioned URLs immutable.

[Soremwar]

@ivawzh

// deps.js
export * as Oak from "https://deno.land/x/oak/mod.ts"; // No name collition
export * as Postgres from "https://deno.land/x/postgres/mod.ts"; // You can choose the library alias yourself

// main.js
import {Oak} from "./deps.ts";

Package source URL is forbidden to changes in the future too

This is a problem for the host of the library to solve, there are many services like Nest.land and Deno.land/x that follow a similar model to the one NPM implements in terms of immutability

Wouldn't deps.ts make optimization (like code-split) hard?

It actually makes it easier, since you can now choose what parts of the library you want to import instead of the whole chunk, an easy example using std

I could pull all the functions I need directly from url just like this

import { ensureDir, ensureFile } from "https://deno.land/std@0.94.0/fs/mod.ts";

But this is an optimization trap (though admitedly not that big of a deal in most cases), cause I'm pulling ALL of the fs functions to my machine, instead of only the ones I need, so I can transform the example above into the following, much lighter version

import { ensureDir } from "https://deno.land/std@0.94.0/fs/ensure_dir.ts";
import { ensureFile } from "https://deno.land/std@0.94.0/fs/ensure_file.ts";