Here is another suggestion regarding resource dependencies: the ability to specify a version. Why? Well if you depend on ox_lib’s dui module, but the server has any version below 3.27.0 installed, you’re gonna get errors. So you would want to have some way to specify that your resource depends on ox_lib version 3.27.0, or rather any version that’s equal to or higher than 3.27.0 and lower than 4.0.0.
@Linden has mentioned this in his suggestion Resource dependency constraints, and said it would be a nuisance due to the different versioning standards and weird syntax etc. So in this proposal I want to elaborate on how I think this should be implemented.
I want to propose to use semantic versioning 2.0.0 to implement this. This versioning standard is used in a lot of the tech industry, and is commonly used in a lot of package managers, like NPM, Composer, Pip and Maven. Therefore I think it is fitting to use this for FiveM resources as well. For more information about semantic versioning, see https://semver.org/.
To indicate the version of a dependency, I want to use a colon (:). Where the value in front of the colon would be the resource name, and the value after the colon the accepted version range. For the version range I want to handle it similarly to how NPM handles this, as this is a proven implementation to allow ranges of versions to be accepted (look back at ox_lib, where we want anything higher than 3.27.0, but lower than 4.0.0 as version 4 might introduce breaking changes). This would result in the following syntax: dependency_name:version range.
The version ranges that NPM accepts allow a lot of different combinations, to read more about this see GitHub - npm/node-semver: The semver parser for node (the one npm uses). Some examples:
-
dependency:1.0.0: Only accept exact version 1.0.0. -
dependency:1.x: Accept any version 1. -
dependency:^1.2.0: Accept any version above 1.2.0, as long as it stays within the same major version.
If we take a look at our example from earlier: we can require ox_lib version 3.27.0 and higher while staying below 4.0.0 by using ox_lib:^3.27.0.
Currently there are many different versioning standards being used, as @Linden said in his suggestion, so you might think that we need to think about that. But I don’t agree, let me explain.
Currently, the version manifest entry is an undocumented maninfest entry. Take a look at Resource manifest - Cfx.re Docs. It’s included in the example (using semver already), but there is no further explanation about it. People just started using it, and rightfully so. But since it’s undocumented, I think we can document this manifest entry now and enforce semantic versioning as the required versioning standard.
How should we handle older resources with different versioning standards? Simple! If its not valid semver, it just doesn’t satisfy whichever version range you’ve specified. Since versioned dependencies will be something new and the version manifest entry is undocumented, we don’t have to take user-defined versioning standards into account as older resources never intended their resources to be used as dependencies with versions attached to them. If those resources want to start being usable as versioned dependencies, they will have to migrate to semantic versioning. And this would mostly be the case for libraries like ox_lib or frameworks like qbx_core (both of which already use semantic versioning for their version manifest entries).
You might disagree with me on this part, but I think it’s important to enforce a certain standard for versioning. Having the version manifest entry undocumented gives us the opportunity to start enforcing this, with almost no downsides.
I would definitely be willing to take this up, and I’ll link the PR for this if I make one.
I’m curious to everyone’s thoughts on this. I think it would improve the overall resource ecosystem, just like my soft dependency proposal from some weeks ago: Soft dependencies for resources.