-
-
Notifications
You must be signed in to change notification settings - Fork 16.3k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
feat: bump router to beta.1 #4752
Conversation
@@ -648,7 +648,8 @@ describe('app.router', function(){ | |||
.expect('122', done); | |||
}) | |||
|
|||
it('should eat everything after /', function(done){ | |||
// TODO: I don't think this is valid anymore? | |||
xit('should eat everything after /', function(done){ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I temporarily disabled this test because I was't sure this was supported in router-beta.1
. If someone could confirm it is, indeed, not, I'll go ahead and remove it. If it is, please let me know how to update the syntax.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is a good question. I'm not sure myself and would need to look to find out. Do you want to do that leg work, or are you asking to defer that to someone else?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was hoping someone else could answer off the top of their heads. That' ok - I'll try to take a look myself. What happens now is that, even after updating the syntax, the :user*
group still matches everything after /
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dougwilson Any reason why router
would use path-to-regexp
3.2.0
? Was that the latest at the time it was released? It's now on 6.2.0
. Would it make sense to target that or would it be too big a leap?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, based on this test from pillarjs/router
which addresses the same situation, I can confirm the above doesn't work anymore with path-to-regexp
3.x
+.
# path-to-regexp@3.2.0
> const p = require('path-to-regexp')
> p.match('/u/:users*')('/u/nfantone/foo/bar')
{
path: '/u/nfantone/foo/bar',
index: 0,
params: { users: [ 'nfantone', 'foo', 'bar' ] }
}
> p.match('/u/:users(.*)')('/u/nfantone/foo/bar')
{
path: '/u/nfantone/foo/bar',
index: 0,
params: { users: 'nfantone/foo/bar' }
}
# path-to-regexp@0.1.7
> const p = require('path-to-regexp')
> '/u/nfantone/foo/bar'.match(p('/u/:users*'))
['/u/nfantone/foo/bar', 'nfantone', '/foo/bar']
What shall we do with the test?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens now is that, even after updating the syntax, the :user* group still matches everything after /.
Gotcha. So the test section this is in is *
, and I see you changed everything to (.*)
instead. Does that change not work for this instance? Also should the name of this test section be updated?
Any reason why router would use path-to-regexp 3.2.0? Was that the latest at the time it was released? It's now on 6.2.0. Would it make sense to target that or would it be too big a leap?
As nuch as I can remember, this is just what someone helped make a pull request for. It would probably be a question for that author of the PR. If you believe you can make it even more up to date, a PR would be wecome in that regard.
So, based on this test from pillarjs/router which addresses the same situation, I can confirm the above doesn't work anymore with path-to-regexp 3.x+.
Ah, I see. We should probably also add thoses tests here too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the test section this is in is , and I see you changed everything to (.) instead. Does that change not work for this instance?
Unfortunately, no. As shown in the snippet above it matches all segments until the end of the path (e.g.: { users: 'nfantone/foo/bar' }
, instead of just nfantone
.
As much as I can remember, this is just what someone helped make a pull request for.
I thought you were the one releasing router@2.0.0-beta.1
? That's where the dependency to path-to-regexp@3.2.0
comes from.
If you believe you can make it even more up to date, a PR would be wlecome in that regard.
I could try and see if router
works with newer versions of path-to-regexp
. Seems like it shouldn't be too hard to pull off.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought you were the one releasing router@2.0.0-beta.1? That's where the dependency to path-to-regexp@3.2.0 comes from. I think you might be confusing it with some other related change.
Sure, I make releases, but a release contains commits, many of which are pull requests that I did not author. I did not author the upgrade of path-to-regexp, you even linked above to the commit where github shows at the top the commit author. I actually did check :) What other change would I be confusing it with, can you elaborate?
This is the pull request: pillarjs/router#42
I could try and see if router works with newer versions of path-to-regexp. Seems like it shouldn't be too hard to pull off.
Awesome, thanks! Do you think we should finish this first to get a release out and then do that, or delay this until that is done? I know you were originally wondering why express 5 keeps getting delayed, and I can say from experience that it is these things that pop up that make it take a while :) I am for just trying to get this out first and then that a look at that upgrade so we can get 5 out the door sooner rather than later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What other change would I be confusing it with, can you elaborate?
Got confused myself, apologies. I even deleted that bit - but your answer got here first.
Do you think we should finish this first to get a release out and then do that, or delay this until that is done?
Done already 👉🏼 pillarjs/router#102. Turns out, it just worked out-of-the-box.
AFAICT, build on AppVeyor is failing for |
Relevant PR blocking this one: pillarjs/router#102 |
How does that PR block updating to router 2.0.0-beta.1 ? The beta.1 is already released. Is there a bug in the beta.1 one release that was not outlined here that prevents using it? Or are you saying you want to close this PR and instead not upgrade to beta.1 and wait for a future router 2.x release? |
Assuming we can easily release |
@dougwilson I can tell at least some of my work, present in this PR has landed, in some form, in the latest beta 😕. Would have been nice to sync on this instead of letting it die without notice. I suppose I can close this now. |
Hi, I'm not sure what you mean letting this die without notice. I didn't close this PR or merge anything from it yet. I was under the understanding from your comment #4752 (comment) that you were going to update this PR once beta.2 of router was released. And yes, apologies I did slip on that one a bit, but I didn't close this PR just like you requested. I'm very confused at what you mean by letting this die, though, as I thought it was waiting for beta.2 to be released and then you were going to update it. Apparently I am confused about that, I'm sorry. I can't do anything right. |
router
to latestbeta.1
version.Some remarks:
pillarjs/router
changelog as I'm not familiar with the internals, so unsure if it's 100% correct - but tests do pass.socket hang up
error, which seem to go away after re-running them (macOS 11.6). Is this expected behaviour?