search

eneajaho / ngx-libs

Angular Libraries Support lists community libs support for each Angular version
https://ngx-libs.com/
MIT License
77 stars 31 forks source link

[feature] support range versions #61

Open nartc opened 1 year ago

nartc commented 1 year ago

Currently, we only support lib version <-> angular version as a 1-1 relationship. In reality, many packages support multiple Angular versions while staying on the same major version. We should come up with a way to support range version. For example:

package-a
    v3.0.0 supports Angular 16+ (signal)
    v2.0.0 supports Angular 14 -> Angular 15 (standalone)
    v1.0.0 supports Angular 9 -> Angular 13 (Ivy)
nartc commented 1 year ago

related to #63

ajitzero commented 1 year ago

If we don't want to modify the existing structures too much, we could set the key as "16+" or "14-15" and deduce the number range accordingly. The function for generating allAvailableVersions can be updated accordingly.

We could replace this: https://github.com/eneajaho/ngx-libs/blob/96bc8fa308dee27c7ed29c5b3aedcc9422bf87a1/libs/models/src/lib-support.interface.ts#L8

With:

// Sample type:
type VersionKey = `${number}` | `${number}-${number}` | `${number}+`

And update this to generate actual versions: https://github.com/eneajaho/ngx-libs/blob/96bc8fa308dee27c7ed29c5b3aedcc9422bf87a1/src/app/utils.ts#L8

A limitation of this approach is how to handle "16+" since we need to know the current latest version. We could hard-code the latest version in some exported constant, and we need to maintain it for every new angular release, or we could try to get the latest number via GitHub API.

The API way has an issue that we can only fetch the latest releases in order, but that could be a back-ported patch release to an older version. We would need to take all release names, trim them to version numbers, and pick the largest value. Hard-coding data will be much simpler since, as it stands, there is a lot of manual work in maintaining the data for this repo.

Another limitation with supporting "16+" is that when a new version, say 17, comes up, the libraries may not actually support v17, but 16+ implies it supports something which didn't exist at the time of writing.

We can avoid both of these options by not supporting "15+" and this should be written as "15-16", and "16+" should be written as "16".