Many thanks for a great project!

This PR add support for generating triple quoted multiple lines even if the string value contains \t characters:

Hjson.stringify(value, { mltabs: true }

It is exposed on the command line as the flag -mltab

I have not figured out why the tab character would be a problem for triple quotes multiple lines. Let me know if I missed the obvious.

Thanks!

Is there a "compact but readable" format for HJSON? Something like https://github.com/lydell/json-stringify-pretty-compact for JSON?

Thanks!

Feel free to provide feedback of any kind. Things you want differently (code style, documentation wording, option name).

I wanted to add tests for this as well but I couldn't get a grip on how these work in this project :).

Hello! First: thanks for this awesome module! It does exactly what I need. I would love to propose multiline strings using the backtick - as introduced with ES5.

e.g.:

{
    string: `multi
        line
        testing
    `
}

Your thoughts?

Hello, Having a giant hjson file containing language strings like:

"en": "hello I am a potentially very long String"

I use it as a Module inside a Javascript App - there it works perfectly in in the current way. Using the cli it give's me the error:

Error: Bad string containing newline at line 153,106

SO basicly there are tons of these cases where I have like:

"en": "hello I am such a long string that I will become continued
in the next line"

It would be awesome if this would't be a such a big deal :-)

I expect hjson

a: 'test'

to represent

{
  "a": "test"
}

But I only get

{
  "a": "'test'"
}

If you don't want to break the spec, please add an option to enable it.

I can't find a comment area for https://news.ycombinator.com/item?id=7435111 so I just say something here. ;-)

Although HJSON is a superset of JSON, but the syntax of YAML is really better than it for humans. I don't think people like to add so much { } and [ ] just for communication between humans (this is a rare case?).

I think a YAML-JSON converter is better than hjson-js.

When trying to extract comments from the following hjson:

{
    a: 1,
    b: 2, # comment
    c: [
        'x',
        'y', #why?
        'z' // zee
    ]
}

you wind up with:

{
  a: 1
  b: 2 # comment
  c:
  [
    "x" #why?
    "y" // zee
    z
  ]
}

That is because extract is putting the comments into a sparse array a which only has elements for entries with comments (this will not hold up if the comments are themselves serialized to JSON). When merge is called, it is looping over all array elements and then transferring the comments to the current value.COMMENTS, but it is using push and losing all index information.

Hello! I'm using hjson in combination with jq to read from hjson on the commandline. See https://jqplay.org/s/pD2ADtE_rn

I would like to be able to write to hjson file via terminal. Right now this is not possible.

Suggested syntax:

hjson -s .test "newstring"

Let me know what you think!

Can you please explain how to use options on var text2 = Hjson.stringify(obj); after everything is being parsed I would like to add quotes to all my original json strings.

var obj = Hjson.parse(output); var text2 = Hjson.stringify(obj);

after this is being done, I get a stripped down code.

I added a simple option "inlineSimple" which formats arrays of simple values comma-separated on a single line. This can improve readability in some cases.

This

[
   "value1"
   "value2"
   "value3"
  10
  11
]

with inlineSimple=true is formatted as:

[ "value1", "value2", "value2", 10, 11 ]

From the README:

emitRootBraces: boolean, show braces for the root object. Default true.

This is a useful option for making my output look neater, so I tried turning it on and spent a lot of time scratching my head wondering why it wasn't working. Turns out this was removed in 2b96ade57e9d675ddc5fe037ff95c6744d89c22e, but:

1. the documentation wasn't updated accordingly, and
2. that commit doesn't explain the justification for the removal.

I notice that the Hjson syntax says:

Note: This feature was previously marked as deprecated but is now officially supported again.

So maybe this option should be brought back again?

raw hjson string

var text = '{\
    "last.access": true,\
    // "last.set": true,\
    // "skills.use": true,\
    // "last.wrap.*": true,\
}';

parse it and then base it back into text

var data = HJSON.parse(text, {keepWsc: true});
text = HJSON.stringify(data, {
    keepWsc: true,
    bracesSameLine: true,
    quotes: 'all',
    separator: true,
    space: '\t',
});

as a result, we get the following string

'{\
    "last.access": true    // "last.set": true,\
    // "skills.use": true,\
    // "last.wrap.*": true,\
}';

repeating these steps several times teaching such a line

'{\
    "last.access": true    // "last.set": true,    // "skills.use": true,    // "last.wrap.*": true,\
}';

I have faced strange behavior of comment processing if it is last entry in object

let parsed = hjson.rt.parse("{\n  a:1/n    // comment 1/n. b: 2\n  //comment 2\n}");
hjson.rt.stringify(parsed) // "{\n  a:1/n    // comment 1/n. b: 2  //comment 2\n}"

Notice that \n disappeared before //comment 2; As use case it means that if user commented last property of object, after parse/stringify methods, commented property will jump to the previous line So this object

{
    a:1
    // b:2
}

after parse/stringify methods will become this

{
    a:1 // b:2
}

I tried to use sortProps option to sort properties, but it didn't work. So I've changed code as the commit to make it work.

Please review my changes, if something more needed, just let me know. Regards.

Is there a particular reason that the hjson/lib/require-config feature only works if the subsequently-required file has a .hjson extension? The feature seems to be disabled if you require a .json file, with subsequent parsing errors. Just wondering what the rationale was here.

This project is a great contribution to sanity, thank you!