feature(http-adapter) Added the application's global prefix to error handlers and global middlewares

[boenrobot]

Added the application's global prefix to the error and not found handlers, and enabled the adapters to register one based on prefix.

PR Checklist

Please check if your PR fulfills the following requirements:

• The commit message follows our guidelines: https://github.com/nestjs/nest/blob/master/CONTRIBUTING.md
• Tests for the changes have been added (for bug fixes / features)
• [N/A] Docs have been added / updated (for bug fixes / features) - The error handler functions and their behaviour is not documented in general.

PR Type

What kind of change does this PR introduce?

[x] Bugfix
[x] Feature
[ ] Code style update (formatting, local variables)
[ ] Refactoring (no functional changes, no api changes)
[ ] Build related changes
[ ] CI related changes
[ ] Other... Please describe:

What is the current behavior?

Attempting to register two applications on the same adapter leads to an error handler conflict, even if the applications have distinct global prefixes set.

Issue Number: N/A

What is the new behavior?

The error handler is set for the global prefix.

For consistency, cors and body parser are also modified with a prefix.

Does this PR introduce a breaking change?

[x] Yes
[ ] No

If someone developed a custom solution to this problem, such as registering the Nest application through a prefixed register() call, they may end up in a situation where the application is prefixed twice. Once by their register call, and a second time by Nest's register call. They would need to remove their solution to remove this double prefixing.

The more typical case of "one application per adapter, with a prefix" is affected, in that if the prefix itself is wrong, the default error handlers would be used. Normal operations, or errors within the application itself would behave as before.

The most typical case of "one application per adapter, without a prefix" is not affected. A prefix "/" is used, which should behave as currently.

Also, the fastify methods now return a void promise that resolves when the registration completes, whereas they previously returned the fastify instance. If someone relied on this behaviour, that would break. Even if they don't, if they call these methods at all, they should await them to ensure they work properly.

Other information

The view engine is not set with a prefix, despite the fact that fastify can do that. The problem is express can't, so for consistency between the adapters, neither one sets it per prefix.

[coveralls]

Pull Request Test Coverage Report for Build 10109

• 1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 95.494%

---

Totals
Change from base Build 10061:	0.0%
Covered Lines:	4472
Relevant Lines:	4683

---

💛 - Coveralls

[boenrobot]

I added the same approach for CORS, and... goddamnit... A bug in fastify-cors' typings showed itself... I've made a PR for them as well: fastify/fastify-cors#50 .

Meanwhile (as well as for future's sake I guess), I've disabled type checking for this line.

[kamilmysliwiec]

Thank you!

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.