Repository navigation
Move req prototype to separate repo #82
Description
The story started in 2014: expressjs/express#2432
I even made the repo where I intended to do this ~2 years ago, but never finished the work.
Since then I have talked with a few people about how the different frameworks and platforms can collaborate. And then @ianstormtaylor kept tweeting about it, so tonight I took the plunge ;)
Here is the initial repo: https://github.com/wesleytodd/express-request
I wrote a few more thoughts about it in the readme for this repo, but I wanted to add here what I think the plan should be:
- Move this repo into the express org. The express org and not
pillarjsbecause this is specifically the Express sugar/compatibility layer. Also, I didn't just create it here because I wanted to get consensus on the direction first. - Branch a v2 where we can make Express 5 compatible updates.
- Branch a v3 to work on this being a wrapper for
http1/2/3. - Implement individual sugar's in separate repos in
pillarjsand integrate them into this allowing for mix-and-match by other implementations. This would be an ongoing process as needed.
The long term goal is that other frameworks and platforms do not need to reinvent the wheel as express evolves. This can also be a place for us to evolve ideas which will ultimately be proposed as additions to the core api's to help improve and evolve them.
If we can get consensus on the api across frameworks and platforms we can then provide shared tools across the framework ecosystems, making the "framework" fungible with the core http features as the shared underlying code.
Other benefits I can think of:
- Let framework maintainers focus on what makes their frameworks great
- Provide consistency, security and spec compliance to common http layer things
- Increase the collaborator base for some of Node's most important modules
- Encourage new and innovative http frameworks without fear of the huge overhead involved in all these little things.
Anyway, I just wanted to get the conversion moving with an actual implementation example. So to start I pulled it out, and over the next week or so I will make open a PR against the master/4.0 because this should be backward compatible.
If everyone is onboard with this approach I will do the same for the response and follow the same approach as listed above.
People who might be interested in this to comment on and or collaborate from other frameworks: @matteocollina @styfle @DonutEspresso @hekike
Note: Obviously before we integrate it there is work to do with documentation and getting it fully up to standards with the express org requirements. Removing probably the whole "History and Reasoning" section, sorry Ian 😄
Activity
wesleytodd commentedon Mar 19, 2020
Ok, here is the new request repo. It would be great if folks can take a look before we publish.
https://github.com/pillarjs/request
cc @expressjs/express-tc @expressjs/triagers
dougwilson commentedon Mar 19, 2020
Awesome @wesleytodd !
I forgot this issue already existed, so I moved my comment from #100 (comment) here to kick off the general conversation.
I think the biggest feedback I have from reviewing them is they... do not actually work independent of each other, yet they are published independently as if they could be. I'm not clear on if the issue is either they they depend on each other by accident or maybe that they should just be a single repo and not two separate repos.
The readme of
express-requestseems to imply it should be able to be used stand alone, but yet following the example and attempting to run it promptly fails due to there being nothis.appdefined. Trying to usereq.freshalso fails, not just becausethis.resis not defined, but also because theresis expected to also have been wrapped with the separate package (which it itself has methods expectingreqto be wrapped with the other package).wesleytodd commentedon Mar 19, 2020
This is a great point! My thought was to copy it over verbatim at first, then discuss what changes we need to make it work outside of Express. I guess I didn't cover that here but my thought is we can move toward it being standalone as we go. Would maybe to discuss this on that repo now that we have it?
dougwilson commentedon Mar 19, 2020
Yep, that is what I figured, and I guess my thought(s) above was the start of such a conversation :)
Sure! I will create an issue there 👍
wesleytodd commentedon Mar 19, 2020
Cool, I have a bunch of thoughts but will reserve them for tomorrow and an issue on that repo. I probably will not get to the
respart tonight since we have the web server frameworks meeting at 6am tomorrow, but I will try to get that one knocked out tomorrow.dougwilson commentedon Mar 19, 2020
Definitely. I wasn't even going to open the issue until tomorrow anyhow. There is likely a lot of thoughts all around, haha.
jonchurch commentedon Mar 30, 2020
Curious if ya'll have thoughts about preserving the git history for
reqandres? I experimented withgit fitler-branchand was able to pull out the files into a new repo while maintaining the entire git history for the selected files.It's fragile, though, since so far as I understand you need to keep the same filepaths aka
lib/request.jsas opposed toindex.jsto keep the history. Eventually the blame would be lost if the file was renamed/moved. But that's no different than normal git history.wesleytodd commentedon Apr 29, 2020
I did, but was not sure how valuable it would be, and was planning on reformatting to standardjs formatting which would break blame anyway.
If you want to keep the history and move them you just need to do the pull out first and then move the file in a new commit. Again though, I am not sure how valuable trying to keep it is do didn't try.