the future of qs

[nlf]

This module has become overly complex and difficult/annoying to maintain. I have no desire to continue maintaining it in its current state. As such, I have two thoughts that I'd like to get some feedback on.

• Rewrite the module

By this I mean a total rewrite, likely removing the majority of features, and following the JSON web forms spec. Some tweaks to the spec will be made for security purposes, but aside from those it will be completely compliant. This would be a major version bump, and would remove many features.

• Hand the module over to someone else

This would mean moving this module out of the hapijs organization entirely, and giving it to someone else. Perhaps @dougwilson has some interest? If not, I'm open to volunteers.

If I take the second route, the JSON web form compliant parser will be written under a totally new name and the new maintainer can choose what they want to support in this module.

I'm opening this issue to gather feedback, so please voice your opinions. I'll be making a final decision on this by the end of next week.

/cc @hueniverse @dougwilson

[dougwilson]

So if something like pillarjs/jshttp were to take over the module, it would be re-written to be JSON web form spec matching anyway, so if there is intention to keep the module as-is with it's strange quirks and stuff, it would probably be best if some other organization/person wanted to take over :)

[hueniverse]

I am dropping it as a built-in option in hapi. You will still be able to BYO query parser. I never used this module so don't care about how it evolves. I do know it has been a pain in the ass to keep track of, and the every other week someone shows up with another idiotic request specific to their use case. Because we allowed a few of those in, it is impossible at this point to say no without pissing people off (and for a good reason since every other stupid request made it in).

I would recommend giving this to someone else to deal with and coming up with a new name for a new module. If no one steps forward, we'll just EOL it.

[nmai]

I'd like to help, but frankly I don't have any experience maintaining anything past (very) small-scale projects.

If no one else volunteers and you're fine with me taking over, let me know. If not, just shut it down and move on.

[kole]

I use this module in a few projects, but would be in favor of transferring it or EOL'ing it when a simplified replacement is ready. Happy to help with that if needed.

[HenrikJoreteg]

Not that anyone asked, but I've switched to https://www.npmjs.com/package/query-string for its light weight (I use it client side too) and that I don't ever need nesting. Do we need a new simplified replacement? Maybe just calling qs "done" and leaving it for those who want to keep using it is an option?

[LinusU]

With the release of 1.0 of multer (an multipart/post-data parsing middleware for express) we switched to be W3C JSON forms compatible. The logic is contained in a separate module called append-field which is an implementation of the algorithm described in the spec, with tests to see that it works as well.

If you decide to rewrite the module, it would be very easy to implement it with append-field since it does all of the complicated logic. You just need to feed it the keys and values.

[jkrems]

Just a side note: Calling it "W3C JSON forms" at this point might be misleading. To quote the W3C website:

Beware. This specification is no longer in active maintenance and the HTML Working Group does not intend to maintain it further.

[dougwilson]

Beware. This specification is no longer in active maintenance and the HTML Working Group does not intend to maintain it further.

Oh, wow. I think the W3C has got fed up with the endless bikeshadding just like the current qs maintainers have.

[hueniverse]

Given the lack of interest I would recommend we EOL this module. Someone can always fork it and publish something else.

[nlf]

Agreed, I think I'm going to EOL it and move on. I'll leave this issue open and put a notice in the README.

@hueniverse when do you plan on removing it from hapi?

[hueniverse]

Probably this week. We have a template for EOL projects in hapi. See https://github.com/hapijs/flod. Also we turn off wiki and issues when we do that.

[Marsup]

How would someone request ownership of the module if issues are closed ? I think it's also good to leave them for historical reasons.

[hueniverse]

I don't mind leaving the issues but I am no longer going to pay any attention to this module. Who is going to keep maintaining this and deal with new issues?

If someone wants to take over this later, I am sure they can figure out who was the last maintainer from npm and contact via email.

[ljharb]

I'd be happy to take it over, if solely to retain compatibility across browsers and older node versions.

[nlf]

@ljharb it's all yours

[ljharb]

Thanks!

[ljharb]

@nlf would you mind also running npm owner add ljharb qs?

[nlf]

done

[ljharb]

<3 thanks!