feat: support parse and stringify with comments #247
Conversation
parse(data, { preserveComments: true } )
parse(data, { commentsKey: ‘internalComments’, preserveComments: true } )
stringify(data, { preserveComments: true })
stringify(data, { commentsKey: ‘internalComments’, preserveComments: true } )
opt in to save comments when parsing and stringify
save comments to internal object key upon parsing,
add the option to save when stringifying data
store comments internally upon parse and stringify to avoid conflicts
when parsing and stringify multiple documents
use platform eol
include tests in default /test/foo.js
Test option for reading (parse) and saving (stringify) comments in configuration file. Test option for reading (parse) and saving (stringify) comments in configuration file using a custom commentsKey.
Option for reading (parse) and saving (stringify) comments in configuration file.
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
'{1,}' can be simplified to '+'
Code scanning / CodeQL Polynomial regular expression used on uncontrolled data https://codeql.github.com/codeql-query-help/javascript/js-polynomial-redos/
Code scanning / CodeQL Polynomial regular expression used on uncontrolled data https://codeql.github.com/codeql-query-help/javascript/js-polynomial-redos/
If line starts with comment character ; or # match line string and push line into line comment array
Comments will be stored using the ‘comments’ key Removes security vulnerability
|
Looking good so far, I'll defer to @lukekarrys for the final review since they started it in #246. This probably will not be looked at till next week at the earliest, just a heads up. |
|
Hi Team and @lukekarrys, any update on this. I also have a similar use case as the above. Do we know when can we expect this to go in ? |
| if (preserveComments) { | ||
| out.comments = commentsDictionary | ||
| } | ||
|
|
There was a problem hiding this comment.
I don't think this will work because the comments key on the returned object could have already been set in the ini text being decoded.
Here's an example:
> require('ini').decode('comments = this is in my ini file')
{ comments: 'this is in my ini file' }
> require('ini').decode('comments = this is in my ini file',{preserveComments:true})
{ comments: {} }
I think the best strategy here would be to follow what json-parse-even-better-errors does and store this data as a symbol on the returned object which can then be read back when encoding. Here's a reference to that code: https://github.com/npm/json-parse-even-better-errors/blob/9355df83b4ce4567711823fc1b40fe63dbeebba5/lib/index.js#L106-L108
Another option would be new methods like decodeWithComments which could return a tuple of [data, comments] which could then be passed back to a new encodeWithComments. But I think the symbols would be a better API if that will work.
ini.js foo.js
parse/decode - store comments as a symbol on object stringify/encode - restore comments using preserveComments flag
|
@lukekarrys - sorry it took so long for this update. I hope this will fix the previous issue when using the internal comment key.
|
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
|
Hi @lukekarrys @wraithgar - just reaching out to see when you might have another chance to review? |
This comment was marked as off-topic.
This comment was marked as off-topic.
support option to save comments when stringifying
#32
#83