Add overloads for { parseAs: "string" } or { parseAs: "buffer" }#1162
Add overloads for { parseAs: "string" } or { parseAs: "buffer" }#1162allevo merged 5 commits intofastify:masterfrom jineshshah36:content-type-parser
Conversation
| done!(null, {}) | ||
| }) | ||
|
|
||
| server.addContentTypeParser('foo/bar', { parseAs: 'string' }, (req, done) => { |
There was a problem hiding this comment.
This conflicts with your docs. It says:
As you can see, now the function signature is (req, body, done) instead of (req, done)
Additionally, if this is allowed, it seems like the body is getting parsed as a string and then ignored. What's the point?
| done!(null, {}) | ||
| }) | ||
|
|
||
| server.addContentTypeParser('foo/bar', { bodyLimit: 20 }, (req, done) => { |
There was a problem hiding this comment.
This conflicts with your docs. It says:
As you can see, now the function signature is (req, body, done) instead of (req, done)
|
Wait I’m confused, is parseAs not required if 3 arguments are passed? If not, what will the body get parsed as? Also, if you do provide three arguments, doesn’t the callback require three arguments? |
|
I already read that but it is incomplete. For example, if I provide parseAs: 'string', but only 2 arguments in the callback, is it just swallowing the body? When does it even make sense to do this: |
|
Maybe the documentation is not so clear. fastify/lib/contentTypeParser.js Lines 68 to 82 in d0d2aa9 The signature is:
|
|
Ok so based on that the following test would be invalid: since it should take 3 arguments in the callback. I've updated the rest of the types and tests accordingly. |
|
Fixed the "The array parameter is supported everywhere in addContentTypeParser". And, I added back "server.addContentTypeParser('foo/bar', {}, (req, done) => {" already. |
allevo
left a comment
There was a problem hiding this comment.
Nice! Thanks!
LGTM
If the content type parser documentation is not clear, would you mind changing it?
|
I would say that it's clear to use from the docs. It was complicated here because the type system needs to account for every possible valid way to use the api. Most of the calls in the tests are redundant ways to do the same thing. It's important that typescript types account for them, but I don't really think it matters if the docs provide them. |
|
The maintainers and the collaborators are not mainly typescript users. If you are interested, we'll be happy to review a PR about a rework of the typescript test suite! |
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Checklist
npm run testandnpm run benchmarkall tests passed