feat(versioning): add devbox versioning module

[burritobill]

Changes

This PR adds devbox versioning, https://www.jetify.com/devbox. Devbox is a local development tool which creates local reproducible environments without docker containers.

Context

This PR is related to #30002
where I was asked to split that PR into one for the versioning, datasource and manager.

I am making these changes on behalf of Culture Amp as we are using renovate internally and have recently migrated to using devbox for our local developer environments.
This PR will ensure that all of our devbox.json files stay up to date with the rest of our repos.

#27543

Documentation (please check one with an [x])

• I have updated the documentation, or
• No documentation update is required

How I've tested my work (please select one)

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[rarkins]

So 1 and 1.2 are versions and not constraints?

If there are no constraints then isVersion() and isValid() should return same results for same inputs?

[burritobill]

So 1 and 1.2 are versions and not constraints?

If there are no constraints then isVersion() and isValid() should return same results for same inputs?

Yes isValid and isVersion return the same results for the same inputs, would you like me to update the tests to include all the same inputs?

Devbox is fairly strict with it's versioning where it only supports "latest", "1", "1.2" and "1.2.3" formatted values, no ranges or constraints are allowed.

I have made it so that "latest" does not show up as a valid version because I don't want renovate to modify that value. Should it still be valid though?

[rarkins]

So 1 and 1.2 are versions and not constraints?
If there are no constraints then isVersion() and isValid() should return same results for same inputs?

Yes isValid and isVersion return the same results for the same inputs, would you like me to update the tests to include all the same inputs?

I think it's a good idea.

I would also like to see a test to make sure that matches('1.2.3', '1') === false.

I have made it so that "latest" does not show up as a valid version because I don't want renovate to modify that value. Should it still be valid though?

Ideally Renovate recognizes it as valid but never tries to update it. Are there lock files involved in devbox?

[burritobill]

So 1 and 1.2 are versions and not constraints?
If there are no constraints then isVersion() and isValid() should return same results for same inputs?

Yes isValid and isVersion return the same results for the same inputs, would you like me to update the tests to include all the same inputs?

I think it's a good idea.

I would also like to see a test to make sure that matches('1.2.3', '1') === false.

I have made it so that "latest" does not show up as a valid version because I don't want renovate to modify that value. Should it still be valid though?

Ideally Renovate recognizes it as valid but never tries to update it. Are there lock files involved in devbox?

Ok I'll add some additional tests then.

Yeah devbox does have a lock file, so those "latest" dependencies will be updated when renovate runs devbox install, but I think that's expected behaviour. I'll add "latest" as a valid version.

[burritobill]

@rarkins So looking at updating the compare function now, when you said 1 and 1.2 are constraints did you mean that if 1 is set it should always find the largest version of 1 e.g. 1.2.3 and if it isn't a constraint then it should match only 1.0.0?
The expected behaviour is that setting 1 will get you the largest version under 2 and for 1.2 it would get you the largest version under 1.3.

Does that mean that .matches('1', '1.2.3') and .matches('1.2', '1.2.3') should return true?

[rarkins]

If .matches('1', '1.2.3') is true then that means 1 is a constraint (like in npm). If .matches('1', '1.2.3') is false then that means 1 behaves like a version (like in Docker tags).

To use another angle, if your current value is 1, and then 2.0.0 is released (but not 2), would you expect to see an upgrade to 2, 2.0.0, or neither?

[burritobill]

If .matches('1', '1.2.3') is true then that means 1 is a constraint (like in npm). If .matches('1', '1.2.3') is false then that means 1 behaves like a version (like in Docker tags).

To use another angle, if your current value is 1, and then 2.0.0 is released (but not 2), would you expect to see an upgrade to 2, 2.0.0, or neither?

Yeah ok I think I understand now, if the value is 1 I would expect renovate to still open the major update PR for version 2.
I'll update this PR to reflect that.

[burritobill]

I have updated that now, let me know if the changes I have made are correct

[rarkins]

To use another angle, if your current value is 1, and then 2.0.0 is released (but not 2), would you expect to see an upgrade to 2, 2.0.0, or neither?

Yeah ok I think I understand now, if the value is 1 I would expect renovate to still open the major update PR for version 2. I'll update this PR to reflect that.

In that case it sounds like you consider 1 to be a value (constraint) but not a version. Your new code/tests don't reflect that though.

In case I have still managed to confused you, can you point me to an example package/datasource for devbox? I'd like to see if it returns results like 1 or if it only returns semantic versions like 1.2.3.

[burritobill]

To use another angle, if your current value is 1, and then 2.0.0 is released (but not 2), would you expect to see an upgrade to 2, 2.0.0, or neither?

Yeah ok I think I understand now, if the value is 1 I would expect renovate to still open the major update PR for version 2. I'll update this PR to reflect that.

In that case it sounds like you consider 1 to be a value (constraint) but not a version. Your new code/tests don't reflect that though.

In case I have still managed to confused you, can you point me to an example package/datasource for devbox? I'd like to see if it returns results like 1 or if it only returns semantic versions like 1.2.3.

Sure an example devbox.json is something like this https://github.com/jetify-com/devbox/blob/main/examples/development/nodejs/nodejs-typescript/devbox.json
Where 18 denotes that it will fetch the latest version matching 18.*.*
And it will fetch that version from https://www.nixhub.io/packages/nodejs

[rarkins]

When I look at https://www.nixhub.io/packages/nodejs I don't see 22 as a version, which implies that it's a constraint, and means that isVersion('22') should return false.

[burritobill]

When I look at https://www.nixhub.io/packages/nodejs I don't see 22 as a version, which implies that it's a constraint, and means that isVersion('22') should return false.

I have updated the PR to match that expectation, does this seem correct now?

[rarkins]

The isVersion() and isValid() tests seems correct now, but the matches() ones now need updating too

[burritobill]

I have add the required urls export so the test will pass now @rarkins

[azdagron]

This is a very exciting feature! The PR seems to have stalled in review. Is there anything the community can do to help move it forward?

[rarkins]

Yes, you can help fix the tests

[burritobill]

Those coverage tests should be passing now @rarkins
Sorry for the huge delay, I have had a bunch of other priorities at work

[renovate-release]

🎉 This PR is included in version 39.78.0 🎉

The release is available on:

• GitHub release
• npm package (@latest dist-tag)
• 39.78.0

Your semantic-release bot 📦🚀