Seems the double quote in arrays are strictly required while key value are loosely allowed to quote or not. There seems to be a discrepancy in the format.

{
    display_name: Products,
    identifier: [name, description], ## Without quotes does NOT work
    order: ['name', 'description', 'active], ## Single quotes does NOT work as well
    hide: ["createdby", "created", "updatedby","updated"] ##Double quotes works, no problem

}

IT would be nice if hjson honored toJSON() in a way consistent with the standard JSON.stringify().

From Mozilla Docs

If an object being stringified has a property named toJSON whose value is a function, then the toJSON() method customizes JSON stringification behavior: instead of the object being serialized, the value returned by the toJSON() method when called will be serialized. JSON.stringify() calls toJSON with one parameter:

• if this object is a property value, the property name
• if it is in an array, the index in the array, as a string
• an empty string if JSON.stringify() was directly called on this object

This could be accomplished by adding the following prior to hjson-stringify.js line 316:

if (typeof(value.toJSON) === 'function')  {
  value = value.toJSON();
}

Hi, I really like this library as it allows me to add comments to my JSON files. That is the only feature I want (for now) as I like to use this as config parser for alfy.

What I noticed however, is that it does two things that keeps me from using this library.

No trailing commas

The output of the stringify call returns key-value pairs without commas. So this is what I get

{
    foo: "bar"
    unicorn: "rainbow"
}

This is probably intended. I think it would be nice if there was an option to at least allow trailing commas to be added.

Quotes around keys

By default, it doesn't quote anything, not even string values. So I used the quotes option and set it to always. This adds quotes around string values, but not around keys. It might make sense if there was an extra option like min, values, always or something. Where always also wraps the keys.

// @sindresorhus

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.

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

Thanks!

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! 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?

After 3.2.0 release the stringify is working incorrectly while using comments -> { keepWsc: true }.
Tested in Kibana Vega editor (which uses hjson.stringify):

Seems it duplicates keys of comments.

Should the library be separated from the command?

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!

It would be useful to have the option of not including undefined members in the serilaized string. Eg

{
  foo: 1
  bar: undefined
}

vs

{
  foo: 1
}

Having a require hook would be great - the boilerplate required to load a file with hjson would be significantly lessened.

Either C style or hash style comments should be used. Both mixed is harder to parse. If it is really human friendly then there should be one ultimate style.

This is technically valid and should never be:

/* text
#foo
bar */

Really cool tool. When trying it out I figured: it would be cool if this could also parse basic env files (by supporting foo=bar as well). However Hjson hangs when running this command:

echo 'foo=bar' | hjson -j

Not that this should be supported, however hjson should output a parse error. ;)

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.

This is a feature suggestion.

At the moment, dsf.parse() is only called on quoteless strings. Should it be fired on any value of any type instead?

The reason is: when DSF types are serialized to JSON, they will be converted to any type, e.g. dsf.math will convert JavaScript number Infinity to JSON string "Inf". JSON does not allow quoteless strings, so those values cannot be parsed back to JavaScript by dsf.parse().

For example example.hjson:

{
  a: Inf
}

would be converted by JSON.stringify(HJSON.parse(fileContent)) (not using dsf.math() here) to:

{
  "a": "Inf"
}

which would be parsed by HJSON.parse(fileContent) as:

{
  a: "Inf"
}

In a nutshell, I think allowing dsf.parse() to be called on any type would allow custom DSF types to be serializable to JSON without information/type loss. It could also create ambiguity, e.g. the parser would assume that JSON "Inf" is JavaScript Infinity, where it could also be a JavaScript string "Inf". There might also be performance penalties. But, providing it's on an optional basis, maybe the benefits would outweigh the drawbacks. At the moment, I cannot really find any mainstream project that allow custom types to be serialized to standard JSON without losing type information.

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
}

When using Hjson.rt.parse and stringify, blank lines in the source are not preserved.

For instance, in the sample test.hjson file, if a blank line is added at line 15 (between text and quote properties), the output of stringify will not include that blank line.

Can this behavior be configured somehow?

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.

Hi, once again, awesome project! This is a "nice to have", but it would optimize the output a lot. The condense mode fails for this case:

{
  transform: [
    {type: "geoshape", projection: "projection"}
  ]
  ...
}

with these options: condense: 100, bracesSameLine: true, keepWsc: true

Expected result (assuming this is not the only key)

{
  transform: [{type: "geoshape", projection: "projection"}]
  ...
}

If this was the whole document, it probably should have even been this:

{transform: [{type: "geoshape", projection: "projection"}]}

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 2b96ade, 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?

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 have an issue with this json. Please advice.

{
  "compilerOptions": {
    "stripInternal": true,
    "skipLibCheck": true,
    /* Basic Options */
    "target": "es5",                          /* Specify ECMAScript target version: 'ES3' (default), 'ES5', 'ES2015', 'ES2016', 'ES2017','ES2018' or 'ESNEXT'. */
    "module": "es2015",                     /* Specify module code generation: 'none', 'commonjs', 'amd', 'system', 'umd', 'es2015', or 'ESNext'. */
    "lib": [
      "es2015", 
      "dom"
    ],                             /* Specify library files to be included in the compilation. */
    // "allowJs": true,                       /* Allow javascript files to be compiled. */
    // "checkJs": true,                       /* Report errors in .js files. */
    // "jsx": "preserve",                     /* Specify JSX code generation: 'preserve', 'react-native', or 'react'. */
    "declaration": true,                   /* Generates corresponding '.d.ts' file. */
    "sourceMap": true,                     /* Generates corresponding '.map' file. */
    // "outFile": "./",                       /* Concatenate and emit output to single file. */
    "outDir": "./@graphty/dist",                        /* Redirect output structure to the directory. */
    "rootDir": "./src",                       /* Specify the root directory of input files. Use to control the output directory structure with --outDir. */
    // "removeComments": true,                /* Do not emit comments to output. */
    // "noEmit": true,                        /* Do not emit outputs. */
    // "importHelpers": true,                 /* Import emit helpers from 'tslib'. */
    // "downlevelIteration": true,            /* Provide full support for iterables in 'for-of', spread, and destructuring when targeting 'ES5' or 'ES3'. */
    // "isolatedModules": true,               /* Transpile each file as a separate module (similar to 'ts.transpileModule'). */

    /* Strict Type-Checking Options */
    "strict": true,                           /* Enable all strict type-checking options. */
    "noImplicitAny": true,                 /* Raise error on expressions and declarations with an implied 'any' type. */
    "strictNullChecks": true,              /* Enable strict null checks. */
    // "strictFunctionTypes": true,           /* Enable strict checking of function types. */
    // "strictPropertyInitialization": true,  /* Enable strict checking of property initialization in classes. */
    // "noImplicitThis": true,                /* Raise error on 'this' expressions with an implied 'any' type. */
    // "alwaysStrict": true,                  /* Parse in strict mode and emit "use strict" for each source file. */

    /* Additional Checks */
    // "noUnusedLocals": true,                /* Report errors on unused locals. */
    // "noUnusedParameters": true,            /* Report errors on unused parameters. */
    // "noImplicitReturns": true,             /* Report error when not all code paths in function return a value. */
    // "noFallthroughCasesInSwitch": true,    /* Report errors for fallthrough cases in switch statement. */

    /* Module Resolution Options */
    "moduleResolution": "node",            /* Specify module resolution strategy: 'node' (Node.js) or 'classic' (TypeScript pre-1.6). */
    "baseUrl": "./",                       /* Base directory to resolve non-absolute module names. */
    "paths": {
      "@angular/core": ["/usr/local/lib/node_modules/@angular/core"],
      "rxjs/*": ["/usr/local/lib/node_modules/rxjs/*"]
    },                           /* A series of entries which re-map imports to lookup locations relative to the 'baseUrl'. */
    // "rootDirs": [],                        /* List of root folders whose combined content represents the structure of the project at runtime. */
    // "typeRoots": [],                       /* List of folders to include type definitions from. */
    // "types": [],                           /* Type declaration files to be included in compilation. */
    // "allowSyntheticDefaultImports": true,  /* Allow default imports from modules with no default export. This does not affect code emit, just typechecking. */
    "esModuleInterop": true,                   /* Enables emit interoperability between CommonJS and ES Modules via creation of namespace objects for all imports. Implies 'allowSyntheticDefaultImports'. */
    // "preserveSymlinks": true,              /* Do not resolve the real path of symlinks. */


    // "sourceRoot": "./",                    /* Specify the location where debugger should locate TypeScript files instead of source locations. */
    // "mapRoot": "./",                       /* Specify the location where debugger should locate map files instead of generated locations. */
    // "inlineSourceMap": true,               /* Emit a single file with source maps instead of having a separate file. */
    "inlineSources": true,                 /* Emit the source alongside the sourcemaps within a single file; requires `--inlineSourceMap` or `--sourceMap` to be set. */

    "experimentalDecorators": true,        /* Enables experimental support for ES7 decorators. */
    "emitDecoratorMetadata": true,         /* Enables experimental support for emitting type metadata for decorators. */
  },
  "files": [
    "./src/index.ts"
  ],
  "angularCompilerOptions": {
    "genDir": "compiled",
    "annotationsAs": "decorators",
    "skipTemplateCodegen": true,
    "strictMetadataEmit": true
  }
}

Great project!

Some users like me use RSS feed readers to catch up with new releases.

However this is not possible with this repository, as it only works when there are GitHub releases. GitHub automatically create releases when Git tags are pushed, so simply adding Git tags should do the work.

There are also some tools that simplify this process such as release-it.

Thanks!

> parse('{a:1}')
{ a: 1 }
> parse('{a:1,a:2}')
{ a: 2 }

I know that hjson-js is just following the spec, but it would be great to have an option, as an unnoticed duplicate key can cause hidden bugs.

Further discussion, related: zaach/jsonlint#13

Hi, not sure if you saw it, but now Kibana (Elasticsearch UI) uses HJSON for the Vega visualizations! And almost immediately I have started receiving requests to add autocomplete support to the ACE editor. The most straightforward (IMO) way to do it would be to use a JSON schema - and simply look up allowed values at each point. Can you think of a good way to add that to HJSON? I saw a PR (a bit stale) for the ACE's JSON autocomplete using Microsoft's intelisense library - I wounder if we can use the same approach? https://github.com/ajaxorg/ace/pull/2885/files

I'm guessing this may be an edge case, but I can't see any documentation on handling key names with single quotes vs double quotes.

In JS I would not expect that these two statements yield different results.

HJSON.parse('{ "a": 1}')
>{ a: 1 } //this is the expected response.

HJSON.parse("{ 'a': 1}")
> { '\'a\'': 1 } // unexpected

Even stranger to me is the behavior of single quotes with whitespace.

HJSON.parse('{ "a b": 1}')
>{ 'a b': 1 } // this is the expected response

HJSON.parse("{ 'a b': 1}")
>Error: Found whitespace in your key name (use quotes to include) at line 1,5 >>>{ 'a b': 1}

In npm 'relaxed-json' there is no difference between the implementations.

Wonderful package ✨
I would like to use it as a dependency. My end users are sometimes targeting browser.

Requiring os prevents this.

• Is there a way to hack past that?
• Or, can we consider making os optional?
• Or, use some kind of dependency injection so I can hard code EOL etc?

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,\
}';

Just wondering is reviver support on the roadmap, see details here.

Since hjson makes it easy to write multi line strings it seems to be a perfect match to write functions in hjson as string and later restore it back to function when parsing, thought?

We have recently updated hjson from 1.7.4 to 1.8.4 and found a regression:

const result = hjson.parse('totally invalid JSON');
console.log(result, typeof result); //emits 'totally invalid JSON string'

The behaviour using 1.7.4 was that this string yielded null as expected since this is not in any way json-ish.

I would like to be able to delete an object property via the delete keyword:

When I do that with hjson, the property is set to undefined.

See example

const path = require('path')
const promisify = require('promisify-node')
const fs = promisify('fs')
const hjson = require('hjson')

const CONFIGFILE = path.resolve(__dirname, '../serverconfig.hjson')

async function get() {
    const file = await fs.readFile(CONFIGFILE)
    return hjson.rt.parse(file.toString())
}

async function set(config) {
    const json = hjson.rt.stringify(config, {
        quotes: 'strings',
        space: 4, // can also use \t for tabs
        bracesSameLine: true,
    })
    await fs.writeFile(CONFIGFILE, json)
}


(async () => {

    var x = await get()
    delete x.example
    await set(x)
    // hjson file still contains `example` property
})()

How to reproduce:

$ sudo npm install -g hjson
This errors:
$ echo "" | hjson
This, too.
$ hjson somefile

The error is

: No such file or directory

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!

Hi,

Could/should the following be valid for hjson?

{ 'a' : 'b' }

The error is:

Error: Found ' ' where a key name was expected (check your syntax or use quotes if the key name includes {}[],: or whitespace) at line 1,5 >>> 'a' : 'b' } ...

The following is valid (both the newline and the removal of the space before the colon seem necessary):

{ 'a': 'b'
}

and produces this output:

{
  "'a'": "'b'"
}

but I would like it to produce the following object:

{ a : 'b' }

When trying to parse nan values using dsf.math, I get an error with the following simple test case:

var hjson = require('hjson');
var dsf = [ hjson.dsf.math() ];
hjson.parse(`{ A: nan, B: 1.0 }`, { dsf: dsf });

Error: End of input while parsing an object (missing '}') at line 1,18 >>> A: nan, B: 1.0 } ...

However, if you put a newline after the nan, then it works fine:

hjson.parse(`{ A: nan,
B: 1.0 }`, { dsf: dsf });

I'm new to hjson, but is there a trick to getting this to work, or is there a bug in the parser?

How does this compare to json5? Would be nice if the readme at least mentioned whats different between the two.

See #16 (comment).

The output of the stringify call returns key-value pairs without commas. So this is what I get

{
    foo: "bar"
    unicorn: "rainbow"
}

This is probably intended. I think it would be nice if there was an option to at least allow commas between elements.

{
    foo: "bar",
    unicorn: "rainbow"
}

I'm attempting to use Hjson web module to parse some Hjson files a game uses for it's mod metadata, and even after updating to 3.2.1, still getting this error. The Java version can parse this just fine but getting some issues on my end.

{
  "name": "Opore Mod",
  "author": "amione",
  "description": "Adds multiple vaults, drills, duos, spectres, walls, forges, extractors, conveyors, liquids, mech units, mech pads. This is actually my first mod, hope you like it because i had alot of issues while making this.
NOTE: Update 30+: Some items will be broken because they cannot be done any other way, like an example the arc. It shoots too slow, but it cannot be faster (maybe anuke will fix the way we edit power turrets some day)


Credits
> Everyone that reports a bug/unbalanced item will be added to the special thanks list (if you dont want to be added just say 'dont add me on the credits list')

> Coding - amione

> Map making - amione, Félix Córvus#3546, Pusheen#3121

> Descriptions and names - amione, LordPotaynut

> Sprites - anuke, amione

> Helped in making of mod on discord - simon#8156, Violet#5020, Nope.avi#4037, HNU Founder.lua#5046

> Feedback on discord - wewemaster#8854, omegaDM#0155, Mwister Cinnabar owo#2702

> Feedback on steam - Tibault, 月之殇, the_red_soul, LordPotaynut, Dockedreaper61",
  "version": "43"
}

replace

if (typeof module === "object") {
  if (typeof require === "function") {
    var os=require('os');
    Hjson.setEndOfLine(os.EOL);
  }
  module.exports=Hjson;
}

to

if (typeof exports === "object") {
  if (typeof process === "object" && Object.prototype.toString.call(process) === "[object process]") {
    var os=require('os');
    Hjson.setEndOfLine(os.EOL);
  }
  if (typeof module === "object") {
    module.exports=Hjson;
  } else {
    exports.Hjson=Hjson;
  }
}

HI

I think it'd be useful if you'd add a README section where visitors can quickly see the differences of Hjson to YAML, that serves a similar purpose and shares several features.

It would be nice if there were a TypeScript definitions file included so that users of supported editors (JS or TS) have completion information. TypeScript users would benefit further by having type checking information and being able to use hjson in TypeScript projects where strict checking is enabled (which is the default for new projects).

Currently, by default when serializing an object from json to hjson, the keys of the object are printed out in the order produced by Object.keys() which isn't particularly deterministic. (Or more precisely it is deterministic based on the order in which keys are populated.) However, it is often useful to have hjson keys rendered in a deterministic ordering such as the ordering producted by sort().