Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix Router.match pathAndMethod to only include layers that have methods #106

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

Gary-Osteen-Q2
Copy link

@Gary-Osteen-Q2 Gary-Osteen-Q2 commented Sep 23, 2020

Fix #105

@dominicegginton
Copy link
Contributor

@Gary-Osteen-Q2 Thanks for submitting a PR to fix #105. I have reviewed the changes. Just need a collaborator to review now. @niftylettuce do you have time to have a look at this? Let me know if there is anything I missed in my review, I am still new to this 😄

@Gary-Osteen-Q2
Copy link
Author

Can anyone take some time to look this over?

Copy link

@jmealo jmealo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Gary-Osteen-Q2: Congratulations on your first open source contribution. You included tests and these changes look good to me. I will be building against your branch while I work on some Open Telemetry improvements.

@jmealo
Copy link

jmealo commented Oct 29, 2020

@niftylettuce: I believe this PR may be required to address this upstream issue:
open-telemetry/opentelemetry-js-contrib#222

@Gary-Osteen-Q2
Copy link
Author

@jmealo Thanks! I've always looked forward to giving back to open source eventually. I am elated to think that it might also fix some upstream issues!

@niftylettuce
Copy link
Contributor

Sorry I dropped the ball on this, is this ready to go? Can a few people look over this and ping me back?

@Gary-Osteen-Q2
Copy link
Author

@niftylettuce it is ready to go from code side. I don't know what else would be needed.

Copy link
Member

@3imed-jaberi 3imed-jaberi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Gary-Osteen-Q2, thank you for your efforts.
I think it's better to keep "path" over "pathOnly" as var/prop name. just for make the update smooth.

@Gary-Osteen-Q2
Copy link
Author

@3imed-jaberi I'm not sure I follow how it would make the update smooth. Logically the layer that gets added to pathOnly have no methods to match in the first place. Whereas pathNotMethod the layer did have a method and it didn't match. Path would then be too generic to me as I would expect others to come in and think that the path matched everything.

@jmealo
Copy link

jmealo commented Nov 13, 2020

@Gary-Osteen-Q2
Copy link
Author

@jmealo pathOnly is used internally by Router.prototype.match which is a @Private method. No outside project should be looking at that variable directly. The ctx.matched gets set at the same place as before in Router.prototype.routes. I don't see how this should affect any other dependent project. Inside Router.prototype.routes the path and ctx.path are unchanged.

@jmealo
Copy link

jmealo commented Mar 22, 2021

@Gary-Osteen-Q2: Sorry for my delayed reply. Your reasoning on a private method is correct in theory, however, the TC39 private methods and getter/setters proposal for JavaScript classes proposal is still a stage 3 draft. Typescript and JSDOC annotations can mark a method as private but JavaScript does not enforce it (yet).

As @3imed-jaberi: pointed out that this PR as implemented would need a MAJOR semver bump because it's an incompatible/breaking change.

I saw an actual monkey patch in the wild that wrapped internal methods of koa-router to set the operation name to the route on outgoing telemetry because there was no way to do it with the public API. npm is full of instrumentation libraries that monkey patch "private" methods.

Instrumentation developers can't really wait/lobby for each upstream projects to change the public API to expose its internals for what they'll consider a niche use case and their users needed better instrumentation yesterday. Since JavaScript doesn't have private methods, we have to tread lightly until there's a TypeScript/ES-Next native ecosystem. Ideally library authors will provide their own instrumentation with time. If that's what you're into you Deno is trying to be that thing.

TLDR: @niftylettuce If we change the path back to pathOnly this is good to go with a PATCH release. If not, this needs to be a MAJOR.

@niftylettuce
Copy link
Contributor

niftylettuce commented Mar 23, 2021

@JacobMGEvans @Gary-Osteen-Q2 I think it is inferred that path is the same as pathOnly (from naming point of view) - is there any reason other than naming to have it renamed? Or perhaps have both and add the new one and use that internally? I would keep it backwards compatible!

Copy link
Member

@3imed-jaberi 3imed-jaberi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM in next bump release

@3imed-jaberi 3imed-jaberi changed the title (#105) Fix Router.match pathAndMethod to only include layers that hav… (#105) Fix Router.match pathAndMethod to only include layers that have methods Jul 9, 2022
@3imed-jaberi
Copy link
Member

@Gary-Osteen-Q2 can you please rebase with the master branch to resolve the conflict and go on here

@3imed-jaberi 3imed-jaberi changed the title (#105) Fix Router.match pathAndMethod to only include layers that have methods Fix Router.match pathAndMethod to only include layers that have methods Apr 2, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
5 participants