Since most developers are familiar with tag/annotation-based documentation, the convention I have started using is similar. Here is a taste:

{ "@comment dependencies": [ "These are the comments for the `dependencies` section.", "The name of the section being commented is included in the key after the `@comment` 'annotation'/'tag' to ensure the keys are unique.", "That is, using just \"@comment\" would not be sufficient to keep keys unique if you need to add another comment at the same level.", "Because JSON doesn't allow a multi-line string or understand a line continuation operator/character, just use an array for each line of the comment.", "Since this is embedded in JSON, the keys should be unique.", "Otherwise JSON validators, such as ones built into IDE's, will complain.", "Or some tools, such as running `npm install something --save`, will rewrite the `package.json` file but with duplicate keys removed.", "", "@package react - Using an `@package` 'annotation` could be how you add comments specific to particular packages." ], "dependencies": { ... }, "scripts": { "@comment build": "This comment is about the build script.", "build": "...", "@comment start": [ "This comment is about the `start` script.", "It is wrapped in an array to allow line formatting.", "When using npm, as opposed to yarn, to run the script, be sure to add ` -- ` before adding the options.", "", "@option {number} --port - The port the server should listen on." ], "start": "...", "@comment test": "This comment is about the test script.", "test": "..." } }

Note: For the dependencies , devDependencies , etc sections, the comment annotations can't be added directly above the individual package dependencies inside the configuration object since npm is expecting the key to be the name of an npm package. Hence the reason for the @comment dependencies .

Note: In certain contexts, such as in the scripts object, some editors/IDEs may complain about the array. In the scripts context, VS Code expects a string for the value -- not an array.