option to specify full url: nock(url).get().reply(200)

[alexkli]

Feature Request

Allow passing in a complete absolute URL (to be mocked) as a single string. For example:

nock("http://example.com/some/path").get().reply(200);

Context

Currently one has to split the url into hostname and path:

nock("http://example.com").get("/some/path").reply(200);

But sometimes you have a complete URL in your test code (for other reasons) and you just want to mock it as is:

const TEST_URL = "http://example.com/some/path";

I ran into this multiple times and every time I do the following without thinking, just to spend some time figuring out why it does not work (no match for request...):

nock(TEST_URL).get().reply(200);

This would be very intuitive, and nock should do the "hard" work of whatever is necessary internally to mock it.

Alternatives

The only options (afaics) right now are:

• duplicate the URL (and its components) in your test code => might be difficult, depending on other parts of the tests
• parse it before passing to nock => tedious

Has the feature been requested before?

I did a quick search on issues but couldn't find anything (but it's hard to search for, "url", "only url" has lots of hits). Sorry if it's a duplicate!

If the feature request is accepted, would you be willing to submit a PR?

Maybe

[Alexsey]

The most straight forward way to parse it is:

const {URL} = require('url')
const testUrl = new URL(TEST_URL)

...

nock(testUrl.origin).get(testUrl.pathname).reply(200);

But I agree that it would be nice to do the same inside nock itself

And if it is not going to be supported - there should be an error risen, because now it's silently ignored and intercept is not working :(

[mastermatt]

@alexkli I understand where this request comes from, I've been there.

But as I've become more knowledgeable on the inner workings of Nock, there are two issues.
First, is that this feature is based under the notion of having a single interceptor or host, however, Nock is fundamentally designed (for better or worse) around having a one-to-many relationship between host/scope to path/interceptor.
My first thoughts on this topic were that it would be nice if Nock would automatically add an interceptor using for a GET method if a Scope was created that included a path. The large assumption about the request's verb method aside, I've learned that a lot of users accidentally create Scopes with paths and if Nock were to auto-magically start creating interceptors in the backend, then it would create a lot unintended behavior.

Unless there were some drastic changes to Nock's API first, I don't think this feature would benefit users.
As @Alexsey pointed out, it would be nice if Nock threw an error when users provided a path on accident. That is a feature that is planned and under WIP, but it's a little stalled atm #1692

I'm going to close this issue, as there doesn't seem to be an actionable items, however, this discussion can always be continued here or in another issue.

[alexkli]

one-to-many relationship between host/scope to path/interceptor

No offense: Having used nock for quite some time, I have (still) no real idea what that sentence means. I believe the internal nock model is not intuitive at all 😉

Would it not be possible to have nock("https://host/basepath") internally simply

• parse the url
• if absolute, create or get the existing nock for the host (surely nock has a list of them?)
• then use the path as base path
• the returned object would have e.g. a get() that would allow no path (= just base path) or a subpath argument (/basepath/subpath)

I wouldn't see how this would be a problem... most likely if I am using the absolute variant I have a single URL to nock and don't care about multiple scopes.

[fent]

came here to request this too

The large assumption about the request's verb method aside, I've learned that a lot of users accidentally create Scopes with paths and if Nock were to auto-magically start creating interceptors in the backend, then it would create a lot unintended behavior.

As @Alexsey pointed out, it would be nice if Nock threw an error when users provided a path on accident. That is a feature that is planned and under WIP, but it's a little stalled atm #1692

so then throw an error in the current version, then add full path support for a future major version

[sennett]

+1 for nock("http://example.com/some/path").get().reply(200). API endpoints stored as single strings in env vars seems easier to me. Same as DB connection strings.

[psytechno604]

+1

@Alexsey - this method makes no sense because it will not work with query string parameters

[Alexsey]

@psytechno604 the node's URL is very flexible - change the code to

nock(testUrl.origin).get(testUrl.path).reply(200);

And it will include the query string as well. Take a looks in the docs on the diagram at the URL strings and URL objects section