* feat: add forcePrerelease option to renderVersionBadge function
Sometimes API would indicate if a version is pre-release while the version number does not have to be semantically a prerelease like in github-release service.
We don't use a isPrerelease that can also force a non-preleases as we trust here developer semantic over API tagging.
* refactor: GithubRelease to use renderVersionBadge
* refactor: GithubTag use renderVersionBadge
* refactor: change forcePrerelease to isPrerelease
* use defaultLabel in renderVersionBadge without tag
As we refactor the codebase to use renderVersionBadge.
some badges need to show default label regardless of tag existance.
This is usefull for cases where the label is dynamic.
This change requires fixing test for npm, not sure how it worked before.
* Refactor AurVersion to use renderVersionBadge
part of #2026
* Refactor CondaVersion to use renderVersionBadge
part of #2026
* Refactor WordpressRequiresVersion to use renderVersionBadge
* add postfix option to renderVersionBadge
* add missing tests for renderVersionBadge
add defaultLabel without tag test
add postfix test
add test for all options together
* Refactor WordpressPluginTestedVersion to use renderVersionBadge
* add prefix override to renderVersionBadge
adds tests for all options with prefix as well
used for #2026 but also usefull for usage letting people override v prefix for versions all over the project once #2026 is done as requested for example in #10574
* Refactor RequiresPHPVersionForType to use renderVersionBadge
* add docstrings for version service
* replace curly quotes with single quotes
* use @example to write sample use cases
* update descriptions
* update jsdoc for rangeStart function
* ignore case if we fall back to string sorting versions
* if no latest MaybeSemVer, try latest pre-MaybeSemVer
* filter versions before we pass it to latestMaybeSemVer()
Adding TypeScript to the frontend and a `.d.ts` file to `core` (see #3742) has multiplied out the different combinations of lint rules. ESLint has support for file-pattern-based overrides, which we've used in some places, but we've also maintained a separate eslintrc for `frontend/`.
This merges the config together, with the strategy of putting all the rules at the top level except where they conflict, and applying settings to exactly the files where they should apply.
This introduces a few new errors in the server but they are true positives – hoisting and lowercase class names – things we don't really need to be doing).
This moves a few helpers from `lib/` to `services/`:
build-status.js
build-status.spec.js
color-formatters.js
color-formatters.spec.js
contributor-count.js
licenses.js
licenses.spec.js
php-version.js
php-version.spec.js
text-formatters.js
text-formatters.spec.js
version.js
version.spec.js
And one from `lib/` to `core/`:
unhandled-rejection.spec.js
The diff is long, but the changes are straightforward.
Ref #2832
