import std module with 'deno_std:'

[Fenzland]

We now can use kv-storage in chrome with:

import storageArea from 'std:kv-storage';

How about support similar API for deno_std?

It may looks like this, and imports the std module with the same version as the deno you installed.

import { serve } from 'deno_std:http/server';

And it's good to keep the same version between deno and deno_std modules.

[kitsonk]

I would be against this, as it introduces "magical" resolution. Let's just keep it simple to URIs.

Also to note, the format for built in module IDs is not standardised yet, it is an outstanding issue with the proposal, so even if we chose, we might choose wrong. The proposal as a whole is Stage 1, which means there is a lot of risk of implementing it ahead of schedule. Also even the kv-storage says the specifier format is not final.

It isn't the first (or last) time that Chrome has jumped the gun on the standards process only to regret it later.

[bartlomieju]

Duplicate of #1922?

[kitsonk]

Kind of sort-of... #1922 was about supporting built-in modules, of which the Deno std library shouldn't/wouldn't be built into the binary. Only kv-storage is at the moment.

[zekth]

I would be against this, as it introduces "magical" resolution. Let's just keep it simple to URIs

I agree with this. Or adding an alias system for the resolution of the uri. For example: from @deno_std:future/....
And this alias is managed by the the user not the runtime itself. Like import path aliases in typescript. Is path aliases supported yet? (Just an idea atm)

It could be nice to have when you want to upgrade your software to another version without rewriting all the files.

[rsp]

@Fenzland First of all, remember about file extensions. So fixing your example:

import { serve } from 'deno_std:http/server.ts';

This already works, but if you run it with:

deno run --importmap=<(echo '{"imports":{"deno_std:http/":"https://deno.land/std/http/"}}') x.ts 

If you are happy with a slash instead of a colon then you can have a single import map for all std modules:

{
  "imports": {
    "std/": "https://deno.land/std/"
  }
}

use it like this:

import { serve } from 'std/http/server.ts';

and run it with:

deno run --importmap=map.json program.ts

You can even go clever with cute prefixes like:

import { serve } from '$/http/server.ts';

by using a map like this:

{
  "imports": {
    "$/": "https://deno.land/std/"
  }
}

In principle there should be no problem in having a default import map like this:

{
  "imports": {
    "$/": "https://deno.land/std/",
    "#/": "https://deno.land/x/",
  }
}

to import all std modules as:

import { serve } from '$/http/server.ts';

and all third party modules as:

import { __ } from '#/dirname/mod.ts';

so this could easily be added in what is already in Deno, but probably being explicit about it would be better.

Or maybe a default prefix for std and x namespaces could be there. I actually kind of like it when I think about it. It would allow using it in libraries, because we cannot expect anyone to run every program with an import map that is potentially merged from multiple maps coming from dependencies (and subdependencies) that the program is using.

[Fenzland]

@rsp Your solution is using improt-map, we need manage version ourself.
But my proposal is some api like std:kv-storage. The very main goal is to keep the vesion of deno_std synchronized with deno we install but not the latest version. (If you install deno-0.16 but run with deno_std-0.22, it'll get crash.)

I agree with @kitsonk about std:kv-storage is not standardised yet. It's too early to add something like this. But once proposal-javascript-standard-library come true, maybe we can reconsider this (I'll reopen this at that time).

[nayeemrmn]

The very main goal is to keep the vesion of deno_std synchronized with deno we install but not the latest version. (If you install deno-0.16 but run with deno_std-0.22, it'll get crash.)

This applies to any dependency, std is actually just another one of these. It'll become less of a problem as built-in APIs stabilise.

What you're proposing is simply a way for people to refer to a common version of std to be chosen at runtime. Even if that was a good idea, treating std specially won't make a significant difference. It's just another popular dependency. You want a more generally applicable solution to peer dependencies.

I understand why this problem hits so hard when thinking of std. Too much of what makes Deno easy to use is constrained to be treated like any other dependency. I hate the idea of seeing many versions of a first party thing in my DENO_DIR. There is a real argument for bundling std with Deno.

[sholladay]

I'm not sure that locking the std version to be the same as the Deno runtime is as good as it sounds. While it does make general maintenance a bit easier, the trade-off is that you are at the mercy of whatever Deno version a user happens to be using, which may or may not have the APIs you expect. That might not be such a big deal if Deno had something like the engines field in package.json. But until then, doing things this way is going to be a bit risky.

[zekth]

It's really risky like @sholladay says. IMO you have to maintain the version manually. Definitely more secure

[rsp]

@sholladay I am also not sure that locking the std version to be the same as the Deno runtime is as good as it sounds, but the alternative is to use the std version that can potentially be incompatible with the Deno runtime, and the question which is more risky cannot really be answered without knowing the forward/backwards compatibility plan of both the Deno core API and the std modules public API, plus the strategy of the compatibility between the two. I tried to raise some of those points in the issue #3320. I think that this is actually more complicated than it may seem. What I mean by that is that there are more things to consider to decide what is better, to lock the version or not, but it also depends on how the Deno API and std modules are actually developed and whether they intend to keep a certain level of compatibility, and if so then what kind of compatibility (backwards compatibility of the Deno core API? forward compatibility of the std modules with future Deno runtime versions? etc.)

[rsp]

@rsp Your solution is using improt-map, we need manage version ourself.

@Fenzland My solution with the import map, if there was a default import map in Deno, could use the std version that is in sync with the Deno itself. I'm not saying that my solution is better than your idea of an api like std:kv-storage, but I'm saying that both of those may not be enough.

The very main goal is to keep the vesion of deno_std synchronized with deno we install but not the latest version. (If you install deno-0.16 but run with deno_std-0.22, it'll get crash.)

Yes, it may crash (unless it is explicitly compatible with older Deno versions, which can be done if thought out carefully) but there is also another problem of writing a program that uses std 0.16 and running it on Deno 0.22. Should it:

1. import std 0.16? (as the program was originally developed with)
2. import std 0.22? (as is in sync with the runtime)

Going for 1 can lead to std being incompatible with the runtime.
Going for 2 can lead to std being incompatible with the program.

This cannot really be answered without knowing how the APIs are going to be developed in the future, that's why I would argue that some strategic decision needs to be made here regarding this. I explained it in more details in #3320.

By the way, I like your idea and I'm curious if you maybe thought about using a similar way to import the 3rd party modules from https://deno.land/x/ in a similar fashion (e.g. to get the latest version that is compatible with the current version of Deno and std modules).

[hayd]

You can also do this [ensure /std matches your code] by prepopulating DENO_DIR/deps.

I do this in deno-lambda for when making artifacts:
https://github.com/hayd/deno-lambda/blob/4b18ea842f63191768b5e57b59f7a455bba741a1/runtime/artifacts#L6-L8