Request: Change how module URLs from deno.land/std/ encode versions to reduce complexity in module provider server

[KSXGitHub]

When I was thinking about #4244, I also think about how such a server should extract module version from a URL.

Flaws in the current approach

The current approach is to use deno.land/std@version/... syntax. A code sample that extracts version would look something like this:

router.get('/:name-and-version', ctx => {
  // This code must parse `name-and-version` according to `std|std@version` syntax
  // making the code more complicated that it needs to be
})

New, simpler syntax

I suggest we should split module name and version, like so:

• std@version → std/version.
• std → std/latest. (TBH, this should be discouraged)

So the above code could be simplified to:

router.get('/std/:version', ctx => {
  // This code does not need to parse version, it's already available
})

This would of course be a breaking change, but Deno has yet reached 1.0 so I think this change is reasonable.

See Also

• Request: Change how module URLs from deno.land/std/ encode versions to reduce complexity in module provider server #4280 (comment)

[KSXGitHub]

@ry Please respond as soon as possible. I am intending on creating a tool that generate JavaScript code and documentation with deno.land/std in mind (to be used in #4244), I want to know whether should I keep this issue in mind.

[sunsetkookaburra]

here's my two cents:
name@version/: presents a view of the library at a point in time
name/version/: presents the idea of multiple versions being maintained at once
I think keeping with the @ is fine (and preferable) and probably is less of a hassle to parse, especially in the case where just the name on its own translates to name/latest.

[KSXGitHub]

@sunsetkookaburra

name/version/: presents the idea of multiple versions being maintained at once

Everyone understands the meaning of software versioning, this should not be an issue.

On the other hand, not only does the parsing of name@version more complicated, but its directory structure is less organized:

name@version:

/
  - foo@0.1.2
  - foo@1.2.3
  - foo@2.3.4
  - bar@7.5.1
  - bar@2.2.2

name/version:

/
  - foo/
  - bar/

[sunsetkookaburra]

@KSXGitHub

On the other hand, not only may the parsing of name@version be more complicated, but its directory structure will be less organized:

It definitely is that way from a conventional end-user-based file-system point of view; the tricky part here is in the way web servers work.

Logically, a website is organised into folders, just like your documents folder for example. Much the same as how it is in your documents folder, it is much neater to keep all versions of a project inside a single folder. A program such as a file server, for example, will treat a url as though it were a tree, and each /name/ a branch on that tree, much like your every-day desktop operating system will do.

From a web (or http) server's point of view, it doesn't know that /one/two/file.txt is a folder one, containing another folder two, which contains file.txt. It merely receives some data saying, "The user wants to see /one/two/file.txt," which looks (to the web server) to be the same sort of data as /anything_you_need?123. This data is merely a string of characters, and in reality its interpretation is up the to web server. It might take the request /one/two/file.txt, flip it, and send it back as a webpage saying, txt.elif/owt/eno/. That part is totally up to the web server.

If deno wanted to reverse its goal of not assuming an index.ts (which it never would), it could look at a url such as /std@v1/http and serve you the /http/mod.ts file, even though you didn't ask for it. This demonstrates that it is up to the web server to decide what you receive, no matter what the url is.
That's why for many websites you can omit the index.html, its a general website convention to shorten a url. But shortening that url hurts specificity, and certainty about what your getting, which is one of the regrets about node.js that ry has resolved in creating deno.

Back to your question about deno's module repository...
On your end, should you prefer locally stored deno modules to appear as std/v1/foo and std/v2/foo, then it is simply a matter of testing the component before @ and using that as the first folder's name, then using the version name as the next folder name, with subsequent folders following the same structure as the rest of the url. A specifier string could also be represented with /std@:version/....

In conclusion:
At the end of the day, it is up to the module repository or file server to deal with giving you the source code, however they please. In the case of deno's module repository, it has elected to give you the files using a versioning system with @s in it to remove the perception that /std is a root folder (its not a folder at all!). The beauty about programming languages is how flexible they are, hence their programmable nature. If there is really something that irks a developer such that they hate to use it, they can wrap it once and forget about it (generally a worst case scenario).

[KSXGitHub]

@sunsetkookaburra

Thanks for your long lesson but I think you mistake my intention: I did not intend to dictate how every module repository server should organize their files. As mention in #4280 (comment), I am intending on creating a repository server program with /std in mind, so I want to ask Ryan whether he is OK with changing the way files are organized.

[kitsonk]

deno.land/std is a redirect server. We don't structure versions. The server simply resolves to the @something to a gittable reference. If someone wanted to create a server that resolved a path to a version, it would require no changes to Deno or the deno.land website to do so.

What deno.land/std supports is working fine and doesn't require any changes in my opinion.

[lucacasonato]

The name@version structure is arguably very easy to understand for users. You have a certain module at a certain version. It also allows you to leave out the version number, something that is not possible with your proposed schema.

Also it will be very difficult to change the import structure we use for deno.land/x and deno.land/std because so many users rely on it. Because of this I am going to close the issue.