Is there a roadmap?

[LinusU]

Is there a roadmap for multer?

There dosen't seem to be too much activity here and there are a lot of bugs open with really simple solutions. I've commented on a few but since I'm not a collaborator I can't close them.

I really like the idea but I still find everything a bit too "messy" right now to include this in my current project. I would really like to work on #123 and #124 and also try and close up most of the bugs. That is if there is interest for this, otherwise I'll probably create something similar since I think that it would be very neat.

Anyhow, not trying to steal anyones project, I just want to help :)

[hacksparrow]

@LinusU thanks for asking and showing the interest to improve multer. I am pretty occupied in my other projects, so this one is lagging quite a bit.

Sent you a collaborator invite, go ahead and make multer better. @jpfluger had some ideas too, it would be great if you guys can get in touch and discuss about it.

[LinusU]

Thank you, I will try to take the weekend to sort thru more of the issues and start thinking on how to move forward. I really appreciate the fast answer!

[jpfluger]

Welcome @LinusU ... I've been busy on other projects as well. Glad you want to jump on board! (Thank you) I have not seen @hacksparrow or other multer contributors define an official roadmap. I do think we all want some stability b/c we use it in all our projects and it gets 2k to 5k downloads per day. So when you have a breaking change, please put in the next major version.

The list below comprises my opinions on various user themes found throughout the Issues. Don't feel like your stepping on my toes with your changes. I'll fit mine in when I have time and if you already haven't beaten me to it.

Security: I put in a busboy pull request to emit the fieldNameSize error constraint b/c it actually doesn't work in multer now. I'd also like to see a parameter be passed into multer specifying fieldnames that should be explicitly allowed to upload files. Without it a hacker/rogue app can send files at will and busboy/multer will begin processing/saving them to disk.

Error-handling for requests hanging: Got pulled away on this one, though I have a possible fix as found in #72. My fix works but it's an "all-or-nothing" approach. But given the process "hangs" perhaps that is the only approach? Opinions? This would most likely close the following issues:. #72, #53 and #73.

Manipulating FIle Name, Destination and Extension: Can't find my post but.... maybe if we pass the entire file object to a function, the user can change dest, filename, extension and then pass the entire file object back and we continue processing. This may be a cleaner/flexible approach. This would be a major version break.

Putting Files in a Single Array: See b3c4447. Setting as default would be a major version break.

Cloud Integration: Yes, this is useful. How to do it, though? My thoughts echo @hacksparrow in #123. I'll add that multer has a lot of mocha tests that get run each time a commit takes place. Cloud features should reflect it in some aspect. I would expect more testing if the cloud is integrated versus kept independent... so probably best to keep it independent. Actually I want to make a shout-out to @dustin-H, who did a really good job in merging multer with the cloud (#102). It was a big step-foward in this process. Yes, I'd love to see this aspect of multer move foward.

There are a number of issues that can be closed. I'll go through them later this night, unless you already have.

Re. contributions to multer. You're experienced on Github, so you know every project does things a little differently. I'll pass-on what I was introduced to in multer.... I've tried to adhere to the ExpressJS team style guide and Git style guide. Also version bumps are in their own commit.

@Fishrock123 gave me this advice for multer:

We usually do all our dev stuff on master like node. If we need to support an older version, use a branch for that version. If you need to do anything huge you want review for, do it in it's own branch and PR it in, like any other PR.

Now, it's not yet documented in the style guide, but we usually don't use the github merge pr button. We find it more sensible to do (assuming bash) $ curl <github_pr_link>.patch | git am (where github_pr_link.patch is like https://github.com/expressjs/multer/pull/50.patch.) - you can pipe github pr patch files directly into the lesser-known git am. Then, we usually do some cleanup on the commits by amending them before committing and pushing.

This has a couple advantages: 1) the patch is added into git history at the addition date, not the date it was created for the PR. 2) nits can be amended easily. 3) It will show the auto as having made the patch but the maintainer as having committed it, which is how it should be.

One last thing: usually we write our commit messages as : add the thing - just mind github's subject name character maximum. :)

[LinusU]

Wow, thank you for the writeup! This is great, I'll start by reading thru all of the source code and then see where I think it's best to start.