Tag @latest

[andreespirela]

Can we add the ability to use the tag @latest so by using it we can get the request map it to the latest version published.
I think this is a nice feature & it will make Documentation so much easier as I don't have to update my documentation to only update the nest.land tag.

If Unstable dropdown will be added at some point, then @latest should only use the latest stable version.

Example:
https://x.nest.land/MandarineTS@latest/mod.ts

CC: @t8

[martonlederer]

I'm not a founder so I can't decide about this, but I think this would be against the whole purpose of nest.land. We exist, to provide the most amount of stability possible. If we add the @latest tag, and a module introduces a breaking change, this stability is gone.

[andreespirela]

Well, @latest would be equal to writing the latest version published. At the end, the user will still have to write @latest at the end of the importing package. So instability can also happen with pointing out to an actual version

Cc @MartonDev

[martonlederer]

No it wouldn't be equal. As I explained earlier, @latest will always point to the latest version, and if let's say someone uses the xy() function from 1.0.0 of a module, and in 1.1.0 of that module, the name of this function changes, for e.g. to az(), the function in the program, importing the @latest tag would still use xy(), but that is already renamed to az() in the latest version

[andreespirela]

Oh okay that makes sense. Fair enough. Closing :).

[zorbyte]

We initially decided to prevent using the latest version to try and solve the issue of breaking changes just randomly popping up and breaking things. I empathise with your situation, as this decision has made your job more demanding. I think it's worth a discussion so that we can evaluate whether or not it would be beneficial to our platform, it's goals and to it's users to support this behaviour.

CC @t8

[zorbyte]

The problems that Marton addressed are the most concerning to me though, which is why I personally believe we shouldn't support this feature. I'll let Tate reopen the issue if he pleases.

[andreespirela]

I would also suggest stability relies a 70% on the package hands. So for example, if MandarineTS is broken and I tell my users to use @latest then it’s really my fault they are using a broken version or for instance, a version with breaking changes. I mean, I can relate to both sides of this story...

I think it’s worth a discussion as well, overall because of things like documentation.

Best.

[andreespirela]

Assumptions that users are using the latest version are also valid such as the Deno 1.2.0 case and the people & documentation using 1.1.3. The Deno documentation assumes you are using the latest version when executing your code...

Anyways, I think it’s worth the discussion, as I have mentioned, I understand both sides of the story and definately if this is a feature that goes against nest.land philosophy then it shouldn’t be applied in any way. I stick to the fact nest.land should protect its philosophy. So I’m ok with whatever decision.

Cc @zorbyte @t8

[SteelAlloy]

Why don't we bring the best of both worlds?
With semver tokens: ^ < ~ =, it would solve most of the issues.
Let me explain. If a version is broken, a bugfix will fix the module without breaking it. Breaking changes will not be installed because of the tokens.
For instance,

https://x.nest.land/MandarineTS@~1.2.0/mod.ts

Would be the same as

https://x.nest.land/MandarineTS@1.2.1/mod.ts

But not

https://x.nest.land/MandarineTS@1.3.0/mod.ts

@andreespirela @zorbyte @t8 what do you think?

[t8]

@oganexon your solution would work perfectly fine if we could trust developers to use semver versioning correctly. I'm really on the fence as to whether or not we can do that.

My stance on this topic is this: Yes, it would make it much easier for documentation purposes and importing latest (stable) versions, but I believe that it proves for a recipe for disaster. For example, an older version of eggs, our CLI, implicitly imported a module called Cliffy. One day, Cliffy was updated, which means that the latest version of Cliffy was also updated. This ended up being a breaking change and caused our CLI to break without us modifying any of its code. In other words, a production piece of software broke without us touching it.

Implicit import urls can also make it extremely difficult for projects to scale, as dependencies may use implicit importing and so may their dependencies. With this, updating a dependency to be compatible with a new version of Deno could wind up starting a chain reaction of other dependencies breaking. This would prove catastrophic to the ecosystem.

I think that this issue pertains more to package managers than registries and CDNs, but I would like to hear some more opinions regarding semver tokens. It could be a solution to this issue, but only if we think it would be wise to assume that developers use semver versioning correctly.

[t8]

After having a contributor meeting, it was decided that the best way to go about deciding a stance on this issue would be by polling the general public. It is critical that we explain the implications that either decision could have on the Deno ecosystem, and we plan to detail these implications on the poll itself.

I'm going to be writing up this poll and revising it throughout the week. You can plan on it being posted either late this week or early next week, as I don't want to over-saturate the various Deno communities with nest.land matters.

I should note that the results of the poll will not determine our final decision to this matter. The team, as a whole, will use the results of the poll to see where the public stands and will make a decision from there.

[dahlia]

I agree that @latest should be avoided as it makes programs depending on @latest vulnerable to breaking changes, but unthinkingly sticking with one fixed version also makes programs vulnerable in terms of IT security, because it doesn't take advantage of security patches. I love @oganexon's idea of adopting some semver operators like ^ and ~, as it prevents people to mindlessly stick with @latest while programs still can depend on the latest patch versions at a time.