-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
v5.0.0 Major Release Proposal #139
Comments
May be worthwhile to investigate testing of the typings, unless it's worthwhile to just go full-bore typescript with koa-body (but that's easily rewrite territory). Some cleanup may be in order, as well. For example, unparsed.js is a file that only exports a single symbol; we ought to be considering either exporting a map instead or gluing the symbol to the prototype of requestbody before it's exported. We're inconsistent in how we handle |
Carrying something over from #140 - potentially worth looking at for 5.0.0 are what options are actually valuable still (an extension of the bullet point for possibly removing Of note, we have toggles for parsing bodies depending on type - and then we have differently prefixed options for handling size constraints for the bodies as well. We do not, however, have a direct way to control multipart body size limits (both fieldsize and upload filesize limits) and instead kick the user to control those via the Here's what I'm thinking. We break up the opts for each "body" type into subobjects, and then from there have the properties for configuring behavior for that body type (e.g. enable/disable, limits, potentially more like a mimetype array depending on if we want to address #72...) ex: app.use(koaBody({
json: {
enabled: false
},
url: {
enabled: true,
limit: '56k'
}
}) That also addresses the problem we're going to start developing if we have to keep prefixing options for certain body types. |
Care to open a 5.0.0 branch to target PRs toward? |
@damianb created branch |
Alright, I'll target it with a PR to handle the removal of the strict shim. |
@damianb be sure to pull from |
oh, i find somethings.
const bodyPromise = Promise.reject(123)
bodyPromise.catch((b) => {
console.log(b);
return b
}).then(v => console.log(v))
// run catch and then
bodyPromise.then((v) => {
console.log(v);
return v;
}).then(val => console.log(val + value))
// just run catch beacuse the code then and catch use next() and the koa do not allow next() called multiple times.
|
Due to #144 I'm really thinking we need to ditch I can't help but wonder how many people actually use Edit: It appears to have originated all the way back in 2014, and I can't find any request that drove having the patchNode/patchKoa toggles themselves. Weird. |
@MarkHerhold Considering we're inherently requiring node 8 now, how do you feel about async/await being used internally? |
Good point - that definitely needs a test case. |
Added a test for what you mentioned in #149. |
We probably need to see if co-body intends to merge/release a fix for this: cojs/co-body#70 |
Let's discuss changes for koa-body v5.0.0. These are the items that I'd like to see rolled into the next release.
co-body
to 6.0.0koa-body
codebase (Test Refactor #136, feature/rework to typescript remove deprecated strict option #213)strict
option (Remove opts.strict compatibility shim #137)patchNode
andpatchKoa
options ❓onError
more predictable (set onError function will get error:'next() called multiple times' #112)I think we'll target late April or early May for this release assuming maintainers and contributors have enough time.
I'm looking forward to hearing thoughts and feedback on this list. 👋
The text was updated successfully, but these errors were encountered: