Improve scaling of version-upgrading code #426

Closed
opened 3 weeks ago by TheMageKing · 3 comments

Hello again.

I got to work adding bowser.js, and along the way ran into a few bugs. The example website provided uses the 'bowser@latest' notation, which isn't supported except by adding a special case to each framework. Further, massive lists of 'if' statements always bothers me.

As such, I propose reworking the version-upgrading code to be more declarative, similar to the existing mapping and resourse-loading code. In fact, the version upgrading system could be rolled into the resources.js dictionary as an additional 'supported versions' array of (requestedVersion , resultingVersion) tuples. requestedVersion could be a target for a comparision, a regex to match with, or a prefix to match with.

In javascript terms, that would work out to this sort of resources.js entry:

// Bowser.js
'bowserJS': {
'path': 'resources/bowser/{version}/bowser.min.jsm'
'versions': [ ['1.9','1.9.4'], ['2','2.11.0'] ]
},

While the 'target for comparision' approach is appealing, it would make pointless bugfix releases of frameworks require extension updates, or else be blocked (in strict mode). A solution to that would be a keyword 'latest', which will match the most recent version. A recursive implementation of the updating code could even allow that to occur as part of a version string: thus given

'versions': [ ['1.9.latest','1.9.4'], ['latest','2.11.0'] ]

to match with, the code would return the follow combinations

(input) (output)
1.9.3 : 1.9.4
1.9.6 : 1.9.4
1.10.5 : 2.11.0
2.2.0 : 2.11.0

ect.

I'd be willing to work on this: would you be willing to accept it? I think it would, in the end, simplify the process and reduce the amount of boilerplate.

Hello again. I got to work adding bowser.js, and along the way ran into a few bugs. The example website provided uses the 'bowser@latest' notation, which isn't supported except by adding a special case to each framework. Further, massive lists of 'if' statements always bothers me. As such, I propose reworking the version-upgrading code to be more declarative, similar to the existing mapping and resourse-loading code. In fact, the version upgrading system could be rolled into the resources.js dictionary as an additional 'supported versions' array of (requestedVersion , resultingVersion) tuples. requestedVersion could be a target for a comparision, a regex to match with, or a prefix to match with. In javascript terms, that would work out to this sort of resources.js entry: // Bowser.js 'bowserJS': { 'path': 'resources/bowser/{version}/bowser.min.jsm' 'versions': [ ['1.9','1.9.4'], ['2','2.11.0'] ] }, While the 'target for comparision' approach is appealing, it would make pointless bugfix releases of frameworks require extension updates, or else be blocked (in strict mode). A solution to that would be a keyword 'latest', which will match the most recent version. A recursive implementation of the updating code could even allow that to occur as part of a version string: thus given 'versions': [ ['1.9.latest','1.9.4'], ['latest','2.11.0'] ] to match with, the code would return the follow combinations (input) (output) 1.9.3 : 1.9.4 1.9.6 : 1.9.4 1.10.5 : 2.11.0 2.2.0 : 2.11.0 ect. I'd be willing to work on this: would you be willing to accept it? I think it would, in the end, simplify the process and reduce the amount of boilerplate.
Poster

(also, on the original impetus: this would allow the code to know at runtime what the most recent version of Extension X it has, allowing it to select that version when given an @latest notation. This is true even if the 'latest' keyword isn't implemented)

(also, on the original impetus: this would allow the code to know at runtime what the most recent version of Extension X it has, allowing it to select that version when given an @latest notation. This is true even if the 'latest' keyword isn't implemented)
Owner

Sounds like a good idea 👍

Just to be sure, you don't want to list all versions in resources.js do you? Because that could get chaotic:

bootstrap: 44 versions
instantsearch.js: 55 versions
jquery: 62 versions
react: 98 versions
algoliasearch: 113 versions
(without alpha, beta, rc, etc.)

Maybe the Cloudflare API will help you: https://api.cdnjs.com/libraries/algoliasearch?fields=name,versions

Sounds like a good idea 👍 Just to be sure, you don't want to list all versions in resources.js do you? Because that could get chaotic: bootstrap: 44 versions instantsearch.js: 55 versions jquery: 62 versions react: 98 versions algoliasearch: 113 versions (without alpha, beta, rc, etc.) Maybe the Cloudflare API will help you: https://api.cdnjs.com/libraries/algoliasearch?fields=name,versions
Poster

oh GOD no. This would basically just be a reformulation of the exisitng code into a more abstracted + elegant system, with less if-then's. Less than/greater than comparators would stil be a fundamental part of the system.

oh GOD no. This would basically just be a reformulation of the exisitng code into a more abstracted + elegant system, with less if-then's. Less than/greater than comparators would stil be a fundamental part of the system.
nobody added the
enhancement
label 2 weeks ago
nobody closed this issue 6 days ago
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.