deno/Lobby

@nayeemrmn

Deno's only principle is the use of URLs. If you want versions, use a host that lets you select versions in the URL. If you want semver, use a library that complies with semver.

That equates to letting the community do it however they want. It may cause different ways to have versioning in the community (f.e. the dem lib is one way to manage versioned code), making some fragmentation that could be avoided.

deno.land just accepts github tags. I guess your suggestion is to only accept tags of the form vX.X.X, to set an example for people to use semver?

That could be a possibility, and the deno.land/x server could resolve version ranges like ^X.X.X by calling the GitHub API to get repo tags, filter to only the ones matching the major number (or minor number for version with major 0), then choose the latest match. Or something. That's almost similar to the idea of having lib authors publish a manifest JSON file with a list of version numbers, or an object mapping versions to URLs, which should be permanently cached by deno.land/x so as not to allow breaking changes by arbitrary change of a version URL).

@kevinkassimo

an election or at least verification process [for libs in /x]

That may work initially, but also as libs are continually updated we'd want them to continue following a standard.

@kitsonk

Identifying packages that self assert they are following semver solves what problem?

@iAmNathanJ wasn't suggesting that that particular action solves a problem. He was suggesting that the fact that there's thousands of dependencies in his project and it all works all of the time is amazing, and hinting that semver is in part responsible for it.

I don't believe anything needs to be centralized in order to have semver.

deno.land/x strictly supporting semver as a CDN does not make things any more centralized than deno.land/x already is.

Anyone desiring not to follow semver could publish on any other server in any way they want. This isn't a feature that is built into Deno runtime. I'm just talking about deno.land/x supporting it, as a way to tell to people that "if you want to be featured on deno.land/x then your lib should follow the standard we've set, but feel free to publish your code in any way on any other server as Deno runtime cares only about URLs."

In web browsers, yes, we can import any script from anywhere. We can also choose to import scripts from unpkg with version numbers. The same could apply to deno.land/x, it can be a web server that people trust for versioned Deno libs, while people would be aware they can run any code from anywhere without the same guarantee.

People are arguing here for Yahoo!, a centralised directory of web sites, categorised all nicely for them. Who goes looking for a website on Yahoo! these days?

I never knew the difference. I thought Google and Yahoo did the same thing: I search, they provide websites. I presume they both categorize websites. But anywho,

If anything, we need the Deno equivalent of Google that can go out, search and categorise code, determine if it is strict or not, if it works with a particular version of Deno or not.

You forgot one thing! It could be this:

If anything, we need the Deno equivalent of Google that can go out, search and categorise code, determine if it is strict or not, determine if it uses semver or not (perhaps looks for a default json manifest file, if it works with a particular version of Deno or not.

And in particular, guarantee that the json manifest file for libs hosted on deno.land/x never ever changes, otherwise that defeats the purpose. This way, if a lib author changes what a version points to, it will break everyone's code instead of silently introducing a backdoor trojan virus cryptominer worm. Still, someone's domain can get hijacked, but at least some malware surface area is reduced.

Google Chrome browser searches websites for manifest.json files, by the way.