vapor

When checking a request's remoteAddress, it's usually the address from which NIO received the request. While that's technically correct, Vapor servers are often hosted behind a reverse-proxy such as nginx. Therefore the original peer's address is often lost. To resolve this, it's not uncommon to set the original peer's address in a header such as X-Forwarded-For.

**Describe the solution you

See #165 results

I wonder whether it would be possible (good?) to display whether or not a package exclusively uses a binaryTarget or not?

What I mean by this is that there are some Swift packages (example) who's sole purpose are to (re)distribute and make available precompiled xcframeworks to SPM. In these scenarios, there is no source code.

We should create a GH action that runs whenever a PR is merged to create an issue for translating the documentation issues in that PR. The issue body should contain a link to the PR so we can link them up. This ensures that the translations don't get out of sync.

Even better if we can add a later to the PR to say no-doc-update required so it doesn't create issues with that label, for instance

The build script for this use (scripts/build.swift) uses deprecated Task APIs. E.g.

scripts/build.swift:48:10: warning: 'launchPath' is deprecated: renamed to 'executableURL'
    task.launchPath = "/usr/bin/env"
         ^
scripts/build.swift:48:10: note: use 'executableURL' instead
    task.launchPath = "/usr/bin/env"
         ^~~~~~~~~~
         executableURL
scripts/build.swi

The way we test Vapor as on onward package doesn't work when the PR is from a fork because it tries to check out a revision that doesn't exist. The main Vapor package checks out both the package and forward provider and uses them both so we should copy that