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

Filter not working as expected #115

Open
Stono opened this issue May 5, 2017 · 6 comments
Open

Filter not working as expected #115

Stono opened this issue May 5, 2017 · 6 comments

Comments

@Stono
Copy link

Stono commented May 5, 2017

Hey,
I'm trying to upgrade to v3.0.0 but there seems to be a change in filter, which I don't know how to work around.

When i say filter, I mean this function:
https://github.com/whitlockjc/json-refs/blob/master/docs/API.md#jsonrefsjsonrefsoptions--object

We used to use this function not exclude certain references from being resolved, see https://github.com/peopledata/td.core/blob/803be57e98516cd5b96ac26295cfa9bacbc971c8/lib/swagger/swaggerResolver.js#L17

Now it appears that that those reference aren't being passed to filter, so we are no longer able to exclude them, and then the resolver is throwing an error.

I know this because I can console.log out the objects being passed to filter, < v3 shows the #/ refs being filtered, >= v3 only ever sees ./ references passed to filter.

Is there a new way that I can stop 'same document' references being resolved?

@whitlockjc
Copy link
Owner

Can you give me an example document that showcases a reference you expect to be passed to the filter function but isn't?

@whitlockjc
Copy link
Owner

My email is in my profile.

@Stono
Copy link
Author

Stono commented May 5, 2017

@whitlockjc I've deleted my previous comment and emailed you just now :-)
Thanks

@whitlockjc
Copy link
Owner

whitlockjc commented May 5, 2017

I don't think this is related but use of relativeBase no longer works. Use location to point to the location where the document is being processed. It shouldn't have an impact but it might. One thing I think that might be related is that [email protected] finds/processes references once no matter how many references to them there may be. So if your code relies on this, that might be what's going on.

Your filter seems to just omit resolving any local reference. So...why not use filter: ['relative', 'remote']?

@Stono
Copy link
Author

Stono commented May 5, 2017

@whitlockjc your thought process went down the same path as mine there, and I removed relativeBase (see the code sample I emailed you) and also tried ['relative', 'remote'] but it was still trying to resolve local refs (thus giving the same error)

@whitlockjc
Copy link
Owner

I think I know what is going on now. Basically, there were two issues that were resolved that are contributing to this:

With [email protected], all remote document resolution is done without the options.filter from the root document being used. The reason for this is it made it possible to have a partially resolved remote reference (#80). Here is an example, let's say I only want to resolve ['relative', 'remote'] references. What should happen to the local references in these remote documents? They will now point to a location that cannot be resolved.

I get what you're trying to do, you want to create a composite but to do that would be extremely difficult to do because to really allow such a thing, you'd have to merge documents instead of dereference them. Then you have to deal with naming conflicts, etc.

I'm open to suggestions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants