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

Update value with saving comment #185

Closed
igor-lemon opened this issue Jul 29, 2020 · 3 comments
Closed

Update value with saving comment #185

igor-lemon opened this issue Jul 29, 2020 · 3 comments
Labels
enhancement New feature or request

Comments

@igor-lemon
Copy link

igor-lemon commented Jul 29, 2020

Hi.
Is it possible to save comments after value changing?

args:
        #somecomment
        objectKey: objectVal #here some comment

After call doc.setIn(['args', 'objectKey'], 'objectValNew') I have

args:
        #somecomment
        objectKey: objectValNew

but I would be want to have

args:
        #somecomment
        objectKey: objectValNew #here some comment
@eemeli eemeli added the enhancement New feature or request label Aug 5, 2020
@eemeli
Copy link
Owner

eemeli commented Aug 5, 2020

That would indeed make sense. The semantics of set and setIn currently consider the comment and anchor to have been a part of the original value, which gets replaced. But that can clearly break stuff:

const doc = YAML.parseDocument(`
  a: &A value
  b: *A
`)
doc.set('a', 'foo')
String(doc)
// Error: Alias node must be after source node

Fixing this might be a breaking change, so it's good that I'm working on yaml@2 just now. At least the anchor should almost certainly stay no matter what; probably the comment as well?

@eemeli eemeli closed this as completed in 0b4be1a Aug 23, 2020
@eemeli
Copy link
Owner

eemeli commented Aug 23, 2020

I managed to solve this for scalar values, which is probably most of the real-world usage. To also make this work for collections, the semantics of set() and some of the other accessors would need to change, such that they always apply a wrapper to the value. That in turn would mean that get()ting a value that you've set() isn't always the same.

Also, routing the internal dependencies such that wrapping input would be possible within accessors would get a little hairy, so I'm going to leave this only mostly fixed, and see if anyone complains.

@igor-lemon
Copy link
Author

Wow! Thanks!

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

No branches or pull requests

2 participants