Array parameters support

[nekrasoft]

• This PR makes it available to send requests like the following:
  curl 'http://host/upload/with/params' -F 'topic=chat10' -F 'members[]=member_one@host.com' -F 'members[]=member_two@host.com' -F 'userfile=@./gplus.png'
• Also it allows to distinguish the parameter type, whether it should be an array or not. It's important when the endpoint excpects the incoming parameters to be exactly of a certain type.
• Fixes the issue the same field's value have different type 'enctype="multipart/form-data" ' #138

[charmander]

if (name.slice(-2) === '[]') {

[felixge]

See #412

[luckylooke]

I am waiting for this, many thanks :)

[tunnckoCore]

Someone or the original author of the PR to add tests would be great, so we can continue. :)

[jhonattanVecchiola]

Funciona

[tunnckoCore]

Lets merge to see if CI is passing, because it's bugged now... That's why PRs from branches is better.

[charmander]

Letting the user control the type of the property in this context has an uncomfortable history. The same API already exists in formidable with files, but I think adding it after the fact to fields has too much potential, for a new feature, to introduce a vulnerability in an upgrade. (Even though it’s semver-major and will be pointed out in the release notes, people will upgrade to it and be satisfied without checking since existing code continues to work.)

Radical suggestion: break backwards compatibility more thoroughly, making fields a URLSearchParams, with API form.fields.get('foo') or form.fields.getAll('foo') (.getAll('foo[]') if the user is following the brackets naming convention).

Or it could just be a new property form.arrays[name] or something. (Advantage: no longer requires a new major version.)

[charmander]

fields is an Object, so realNames on Object.prototype will produce strange results. Object.prototype.hasOwnProperty.call(fields, realName) is the more consistent way to do this.

[tunnckoCore]

Yea, exactly, was thinking about that too.

[tunnckoCore]

Agree. This definitely should/will be considered in future versions and modernizing the code.

[charmander]

(Ah, it’s behind multiples now, in 2ca8f2c, so more consistent and less of a hazard – nice! Still a breaking change, though, and if there’s a package that wraps this one and always specifies multiples: true….)

[tunnckoCore]

Please try npm install formidable@canary - preview of v2. The API is almost the same, check the docs or open new issue if there's some problem.