You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat: Add support for pretty-printing of the JSON input
Comments can be retained in the consistently formatted output. Quotes around object keys can be stripped if the key is an identifier name (JSON5).
BREAKING CHANGE: The option for pretty-printing *invalid input* has been renamed:
-p (--pretty-print) ==> -P (--pretty-print-invalid)
The option `-p (--pretty-print)` will newly prettify the raw (text) input instead of formatting the parsed JSON object.
Copy file name to clipboardExpand all lines: README.md
+94-17Lines changed: 94 additions & 17 deletions
Original file line number
Diff line number
Diff line change
@@ -17,6 +17,7 @@ This is a fork of the original package with the following enhancements:
17
17
* Optionally recognizes JavaScript-style comments and single quoted strings.
18
18
* Optionally ignores trailing commas and reports duplicate object keys as an error.
19
19
* Supports [JSON Schema] drafts 04, 06 and 07.
20
+
* Offers pretty-printing including comment-stripping and object keys without quotes (JSON5).
20
21
* Prefers the native JSON parser if possible to run [7x faster than the custom parser].
21
22
* Reports errors with rich additional information. From the schema validation too.
22
23
* Implements JavaScript modules using [UMD] to work everywhere.
@@ -76,25 +77,32 @@ By default, `jsonlint` will either report a syntax error with details or pretty-
76
77
77
78
Usage: jsonlint [options] [<file or directory> ...]
78
79
79
-
JSON parser and validator - checks syntax and semantics of JSON data.
80
+
JSON parser, syntax and schema validator and pretty-printer.
80
81
81
82
Options:
82
-
-s, --sort-keys sort object keys
83
+
-s, --sort-keys sort object keys (not when prettifying)
83
84
-E, --extensions [ext] file extensions to process for directory walk
84
85
(default: ["json","JSON"])
85
86
-i, --in-place overwrite the input files
86
-
-t, --indent [char] characters to use for indentation (default: " ")
87
+
-t, --indent [char] characters to use for indentation
88
+
(default: " ")
87
89
-c, --compact compact error display
88
-
-M, --mode set other parsing flags according to a format type
90
+
-M, --mode [mode] set other parsing flags according to a format
91
+
type (default: "json")
89
92
-C, --comments recognize and ignore JavaScript-style comments
90
93
-S, --single-quoted-strings support single quotes as string delimiters
91
-
-T, --trailing-commas' ignore trailing commas in objects and arrays
94
+
-T, --trailing-commas ignore trailing commas in objects and arrays
92
95
-D, --no-duplicate-keys report duplicate object keys as an error
93
96
-V, --validate [file] JSON schema file to use for validation
94
-
-e, --environment [env] which specification of JSON Schema
95
-
the validation file uses
97
+
-e, --environment [env] which specification of JSON Schema the
98
+
validation file uses
96
99
-q, --quiet do not print the parsed json to stdin
97
-
-p, --pretty-print force pretty-printing even for invalid input
100
+
-p, --pretty-print prettify the input instead of stringifying
101
+
the parsed object
102
+
-P, --pretty-print-invalid force pretty-printing even for invalid input
103
+
--prune-comments omit comments from the prettified output
104
+
--strip-object-keys strip quotes from object keys if possible
105
+
(JSON5)
98
106
-v, --version output the version number
99
107
-h, --help output usage information
100
108
@@ -138,21 +146,21 @@ The exported `parse` method is compatible with the native `JSON.parse` method. T
138
146
139
147
The `parse` method offers more detailed [error information](#error-handling), than the native `JSON.parse` method and it supports additional parsing options:
You can parse a JSON string to an array of tokens and print it back to a string with some changes applied. It can be unification of whitespace or tripping comments, for example. (Raw token values must be enabled when tokenizing the JSON input.)
188
+
189
+
```js
190
+
const { tokenize } =require('@prantlf/jsonlint')
191
+
consttokens=tokenize('string with JSON data', { rawTokens:true })
The [`tokenize`](#tokenizing) method accepts options in the second optional parameter. See the [`tokenize`](#tokenizing) method above for more information.
197
+
198
+
The [`print`](#pretty-printing) method accepts an object `options` as the second optional parameter. The following properties will be recognized there:
The `tokenize` method accepts options in the second optional parameter. See the [`parse`](#module-interface) method above for the shared options. There are several additional options supported for the tokenization:
|`rawTokens`| adds a `raw` property with the original string from the JSON input |
249
+
|`tokenLocations`| adds a `location` property with start, end and length of the original string from the JSON input |
250
+
|`tokenPaths`| adds a `path` property with an array of keys and array indexes "on the way to" the token's value |
251
+
252
+
If you want to retain comments or whitespace for pretty-printing, for example, set `rawTokens` to true. (The [`print`](#pretty-printing) method requires tokens produced with this flag enabled.)
253
+
177
254
### Performance
178
255
179
256
This is a part of an output from the [parser benchmark], when parsing a 4.2 KB formatted string ([package.json](./package.json)) with Node.js 10.15.3:
180
257
181
258
the built-in parser x 68,212 ops/sec ±0.86% (87 runs sampled)
182
259
the pure jju parser x 10,234 ops/sec ±1.08% (89 runs sampled)
183
260
the extended jju parser x 10,210 ops/sec ±1.26% (88 runs sampled)
184
-
the tokenisable jju parser x 8,832 ops/sec ±0.92% (89 runs sampled)
185
-
the tokenising jju parser x 7,911 ops/sec ±1.05% (86 runs sampled)
261
+
the tokenizable jju parser x 8,832 ops/sec ±0.92% (89 runs sampled)
262
+
the tokenizing jju parser x 7,911 ops/sec ±1.05% (86 runs sampled)
186
263
187
264
A custom JSON parser is [a lot slower] than the built-in one. However, it is more important to have a [clear error reporting] than the highest speed in scenarios like parsing configuration files. Extending the parser with the support for comments and single-quoted strings does not affect the performance. Making the parser collect tokens and their locations decreases the performance a bit.
0 commit comments