-
-
Notifications
You must be signed in to change notification settings - Fork 117
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
Resolve aliases when using getIn
#386
Comments
I like this idea. I'd really rather not add any new methods specifically for it, though. I'm rather tempted to say that going from Or is there a potential real-world use where this might break something? |
I think whether or not this is a breaking change really depends on how you look at it. For me this wouldn’t break anything, nor can I think of any potential real-world use cases that could break, but it is a change of behaviour. Another alternative would be to accept an options object: interface GetOptions {
keepScalar?: boolean;
resolveAnchors?: boolean;
}
doc.getIn(path: Iterable<unknown>, options?: boolean | GetOptions) Passing I think it also makes sense to resolve the alias node itself if that would be the result. So given the example above, the following two lines would be equivalent: console.dir(doc.getIn(['foo'], true));
console.dir(doc.getIn(['fooz', 'baz'], true)); |
I’ll gladly provide a pull request if we reach concensus about the options format. :) |
Is your feature request related to a problem? Please describe.
I have a situation where I have a list of paths from a YAML document. I need to map these paths to the location in the document source code. This can be done using the following code:
Unfortunately the last statement doesn’t work, because
getIn
doesn’t resolve aliases.Describe the solution you'd like
I would love for
getIn
to be able to resolve aliases.Describe alternatives you've considered
Possibly new methods can be introduced:
resolve(key, keepScalar?)
andresolveIn(path, keepScalar?)
. This would avoid breaking changes inget
andgetIn
respectively.It’s possible to do this manually, but I think it’s a useful feature for this library to support out of the box.
Additional context
We use this together with the
jsonschema
package. Apart from this issue, it’s working amazing!The text was updated successfully, but these errors were encountered: