* feat: support authentication on Libraries.io requests
* feat: wire up libraries.io config and api provider instantiation
* feat: create libraries.io and bower base classes
* refactor: tweak libraries/bower service classes and tests
* rename request fetcher function/arg
* throw exception when no tokens available
* cleanup old value
Co-authored-by: repo-ranger[bot] <39074581+repo-ranger[bot]@users.noreply.github.com>
* convert [homebrew,hsts,itunes,jenkins,jetbrains] classes to static props
* Run the prettier across the files
* Updated the correct values in logos.spec.js
* revert back the logos.spec.js changes
* Completed refactoring of [lgtm liberapay librariesio localizely luarocks]
* Convert defaultBadgeData to object
Co-authored-by: Jabbar Memon <jabbar@zoop.one>
This takes another pass over the modern services to remove unused code. I switched the shared code to use a function instead of a class and removed the indirection in the route params which led to skew between the route and examples and wasn't making things any clearer.
The route helper functions are fairly well isolated from the rest of BaseService, with a few convenient entry points. They are easier to test in isolation.
The way the code was written before, `pathToRegexp` was invoked once for every request, which seems inefficient.
`route` was validated when it was used, though it seems more helpful to validate it up front.
This breaks out `_makeFullUrl`, `_regex`, `_regexFromPath` into new helper functions `makeFullUrl`, `assertValidRoute`, `prepareRoute`, and `namedParamsForMatch`.
It adds validation to route, and updates the services without patterns to include one, in order to pass the new validation rules.
The term “url” is overloaded in services, to refer to the Shields route and also the API URL. Calling the Shields URL a “route” is on the whole more descriptive, and makes it clearer and more obvious which one of these we’re talking about. It’s a small thing, though seems like an improvement.
We have a few functions called `buildUrl`. I’ve renamed them to `buildRoute` when they refer to routes, and left them as `buildUrl` when they refer to API URLs.
I included a minor style tweak and some formatting cleanup in `TUTORIAL.md`.
This is consistent with what we're pretty much already doing, and saves us from making the request during code review.
These were all autofixed and most of them seem easier to read. Some in the legacy services should be rewritten in more legible forms during refactor (ie using intermediate variables, or using request’s qs option). There are some in helper functions and elsewhere that should get rewritten separately. I don't want to change them in this PR because the changes will get lost in this diff, though we could identify them here and fix them before or just after.
I had to track down the right lint rule for this. We have no-useless-rename for destructuring and import/export. The one for object literals is object-shorthand.
all-badge-examples is a common cause of merge conflicts. It’s difficult to adjust the badge categorization in that file – or to understand the diff – because it requires moving a block from one point to another. It’s much easier to edit a badge’s category in one place.
This starts the process of breaking up what’s left of that file, following up on the work from #1931. New-style services can only be in one category, which means legacy service examples have to be split along category lines. I split out separate legacy service classes where I could do so easily, leaving behind the ones which require more work, for one reason or another.
