src/content/docs/linter/rules/no-top-level-literals.mdx
import { Tabs, TabItem } from '@astrojs/starlight/components';
<Tabs> <TabItem label="JSON (and super languages)" icon="seti:json"> :::note This rule has been implemented but not released yet. It will be available in the next release. ::: :::caution This rule is part of the [nursery](/linter/#nursery) group. This means that it is experimental and the behavior can change at any time. ::: ## Summary - Diagnostic Category: [`lint/nursery/noTopLevelLiterals`](/reference/diagnostics#diagnostic-category) - This rule doesn't have a fix. - The default severity of this rule is [**information**](/reference/diagnostics#information). - Sources: - Same as [`json/top-level-interop`](https://github.com/eslint/json/blob/main/docs/rules/top-level-interop.md){
"linter": {
"rules": {
"nursery": {
"noTopLevelLiterals": "error"
}
}
}
}
Require the JSON top-level value to be an array or object.
The JSON specification technically allows any JSON value (object, array, string, number, boolean, or null) to be used as the top-level element of a JSON document. However, some older JSON parsers, especially those created before RFC 7158/4627 was fully adopted, only support objects or arrays as the root element.
Additionally, some security practices (such as those preventing JSON hijacking attacks) rely on the assumption that the top-level value is an object or array. Using an object or array at the top level also provides better extensibility for your data structures over time.
"just a string"
42
true
null
{
"property": "value",
"otherProperty": 123
}
["element", "anotherElement"]
{}
[]