diff --git a/.remarkrc b/.remarkrc
index 10cfc972f562d..9bc0d983a61f4 100644
--- a/.remarkrc
+++ b/.remarkrc
@@ -6,7 +6,6 @@
["remark-lint-first-heading-level", false],
["remark-lint-maximum-line-length", false],
["remark-lint-no-file-name-articles", false],
- ["remark-lint-no-multiple-toplevel-headings", false],
["remark-lint-no-shortcut-reference-link", false],
["remark-lint-no-trailing-spaces", false],
["remark-lint-no-undefined-references", false],
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index ebd72e466bb96..cd76eeb948d3f 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -11,7 +11,7 @@ expectations the Node Foundation requires of its contributors.
* A **Contributor** is any individual creating or commenting on an issue or pull request.
* A **Collaborator** is a subset of contributors who have been given write access to the repository.
-# Logging Issues
+## Logging Issues
Log an issue for any question or problem you might have. When in doubt, log an issue,
any additional policies about what to include will be provided in the responses. The only
@@ -23,7 +23,7 @@ add appropriate metadata before the issue is addressed.
Please be courteous, respectful, and every participant is expected to follow the
project's Code of Conduct.
-# Contributions
+## Contributions
Any change to resources in this repository must be through pull requests. This applies to all changes
to documentation, code, binary files, etc. Even long term collaborators must use
@@ -53,7 +53,7 @@ small minority of issues are brought to the Technical Steering Committee for
resolution. Discussion and compromise among collaborators is the default
resolution mechanism.
-# Becoming a Collaborator
+## Becoming a Collaborator
Individuals with non-trivial contributions may be added as Collaborators.
Collaborators are expected to follow this policy and continue to send pull
diff --git a/locale/ar/docs/guides/publishing-napi-modules.md b/locale/ar/docs/guides/publishing-napi-modules.md
index 2820656a107b3..3ca19e1443cd2 100644
--- a/locale/ar/docs/guides/publishing-napi-modules.md
+++ b/locale/ar/docs/guides/publishing-napi-modules.md
@@ -22,7 +22,7 @@ layout: docs.hbs
حتى يتمكن المستخدم من تثبيت نسخة خاصة بالـ N-API، يجب عليه تنفيذ الأمر `npm install iotivity-node@n-api`.
لمزيد من المعلومات حول كيفية استعمال الوسوم مع مدير حزم النود، قم بزيارة ["Using dist-tags"][].
-# كيفية تقديم اعتماد في نسخة لحزمة خاصة بـ N-API
+## كيفية تقديم اعتماد في نسخة لحزمة خاصة بـ N-API
لإضافة نسخة خاصة بالـ N-API من حزمة `iotivity-node` كإعتماد ، يجب على ملف `package.json` أن يبدو كما يلي:
```json
diff --git a/locale/en/blog/community/quality-with-speed.md b/locale/en/blog/community/quality-with-speed.md
index c121bafb90ffb..06e17c6c3217c 100644
--- a/locale/en/blog/community/quality-with-speed.md
+++ b/locale/en/blog/community/quality-with-speed.md
@@ -27,7 +27,7 @@ are in support of this goal.
This is our take on how these activities fit together.
-# Key strategies
+## Key strategies
Several key strategies are in place to build the safety
net in order to enable change/innovation while maintaining
@@ -45,7 +45,7 @@ quality. These include:
* Performance Benchmarks
* Tools
-# Release Types
+## Release Types
The Node.js project maintains 3 key types of releases
@@ -61,7 +61,7 @@ to Current and LTS releases in a more controlled manner,
such that the level of quality/stability increases at
each level.
-## Nightlies
+### Nightlies
These are built from master and contain the very latest changes
that have been landed. If you want to try out the bleeding edge
@@ -69,7 +69,7 @@ these are the binaries to use. There is no additional testing
on these releases, however, the standard Node.js unit tests are
run for each change landed so these will most often be usable.
-## Current
+### Current
Changes which have landed in master are backported to Current
on a regular basis. In general all changes that land in master
@@ -92,7 +92,7 @@ If you want to try out the latest with a reasonable expectation
that your application will continue to run, these are the releases
to use.
-## LTS
+### LTS
Once changes have been proven in the Current stream, they are candidates
for the LTS streams. In the first stage of LTS (Active)
@@ -122,7 +122,7 @@ You can read more about the LTS releases [here](https://github.com/nodejs/lts).
If you want the best level of stability/quality for your production
applications these are the releases to use.
-# Change flow processes
+## Change flow processes
We've already touched on this in the discussion on the different release
types but we'll expand on this strategy here.
@@ -166,7 +166,7 @@ where those changes can be used/validated and a funnel through which
these can flow in an appropriate manner into releases used by more
risk-averse community members.
-# Enhancement Proposal Process
+## Enhancement Proposal Process
Some changes are of such scope that they cannot simply be reviewed in a
pull request. There are often larger questions that will factor into the
@@ -184,7 +184,7 @@ on implementation. The result being that the merits of the concept can be
discussed at the appropriate level of abstraction without having to
review all of the technical details.
-# Automation and Testing
+## Automation and Testing
Automation and Testing are key strategies that go hand in hand in allowing
rapid change in a safe manner.
@@ -215,7 +215,7 @@ These levels include:
* Development Workflows
* Use Case Testing
-## Functional Tests
+### Functional Tests
Functional tests are the first level of defense. Our collaborator guidelines
require test cases for all new features added, and our collaborators set a
@@ -232,7 +232,7 @@ the tests pass reliably and consistently. If you watch the continuous
integration (ci) runs you will see that they are mostly green
and intermittent failures are rare.
-## Platform/OS Coverage
+### Platform/OS Coverage
This is not a type of test by itself. But by applying the strategy of
running tests across a broad range of platforms and OS types and levels it
@@ -247,7 +247,7 @@ Our strategy is to test on a broad range of platforms both to ensure Node.js
works on our supported platforms, but also to leverage the diversity to
uncover as many problems as early as possible.
-## Dependency Testing
+### Dependency Testing
Node.js has a number of key dependencies. It's important that we ensure
that any changes we apply to those dependencies don't have a negative effect.
@@ -259,7 +259,7 @@ making changes to the V8 tree.
We don't currently run the tests for other dependencies, but the delta in
the Node.js tree for the dependencies other than V8 is more limited.
-## Module Tests
+### Module Tests
Module tests are the next level of defense. They help to validate that
changes are not going to break for end users. Most applications use
@@ -274,7 +274,7 @@ Current and LTS releases and we are working to increase that frequency.
You can read more about our module testing efforts in
[https://github.com/nodejs/citgm/](https://github.com/nodejs/citgm/).
-## Stress Tests
+### Stress Tests
Some problems only surface after running for a long time. Stress tests help
to flush those out by running certain scenarios over a prolonged period
@@ -283,7 +283,7 @@ of time.
We don't have any stress tests running at this point but it will be our next
priority after we have module testing running at an appropriate frequency.
-## Development Workflows
+### Development Workflows
Development Workflows is another level up from Module Testing. It aims
to test common development workflows to ensure changes will not introduce
@@ -292,7 +292,7 @@ any regressions to those flows.
These are more work to put in place and run but they will be next on our
list after getting stress tests in place.
-## Use Case Testing
+### Use Case Testing
This would be the next logical step after Development Workflows, testing
for the common use cases for Node.js.
@@ -301,7 +301,7 @@ Our current strategy is to get some of this coverage through the
benchmarking that we put in place, but it is another area we can work
on once we have the other levels of testing in place.
-# Performance Benchmarks
+## Performance Benchmarks
While ensuring functional stability is good, its not enough. We also need
to make sure that performance is not degraded as changes flow in.
@@ -318,7 +318,7 @@ across the major Node.js versions. You can view this data at:
This data allows us to ensure we avoid performance regressions as
changes flow in.
-# In Summary
+## In Summary
This may have been a bit of a long read but I hope it has put a number
of the activities you may have seen in the Node.js community over the last
diff --git a/locale/en/blog/vulnerability/december-2019-security-releases.md b/locale/en/blog/vulnerability/december-2019-security-releases.md
index 0716782c0ff27..15ca7d91facb6 100644
--- a/locale/en/blog/vulnerability/december-2019-security-releases.md
+++ b/locale/en/blog/vulnerability/december-2019-security-releases.md
@@ -52,21 +52,21 @@ Please note that this will be the final release of the v8.x line as support ends
--------------------------------------
-# Summary
+## Summary
The Node.js project will release new versions of all supported release lines on or shortly after Tuesday December 17, 2019 UTC. For versions 8, 10, and 12 the only update to the runtime in these releases will be an updated version of npm addressing the vulnerability announced in https://blog.npmjs.org/post/189618601100/binary-planting-with-the-npm-cli. Version 13, while still being a security release, will include all commits that were scheduled to be included in the originally scheduled release.
In the meantime, users should update to npm 6.13.4 by following the instructions provided in the npm advisory. As a general rule, avoid running npm in production environments.
-# Impact
+## Impact
All versions of Node.js are vulnerable including the LTS and current releases: Node.js 8 (LTS "Carbon"), Node.js 10 (LTS "Dubnium") , Node.js 12 (LTS "Erbium"), and Node.js 13.
-# Release timing
+## Release timing
Releases will be available at, or shortly after, Tuesday, December 17, 2019 UTC.
-# Contact and future updates
+## Contact and future updates
The current Node.js security policy can be found at https://nodejs.org/en/security/. Please follow the process outlined in https://github.com/nodejs/node/blob/master/SECURITY.md if you wish to report a vulnerability in Node.js.
diff --git a/locale/en/blog/vulnerability/february-2020-security-releases.md b/locale/en/blog/vulnerability/february-2020-security-releases.md
index c7a02ddf4ab60..f26657fa0f237 100644
--- a/locale/en/blog/vulnerability/february-2020-security-releases.md
+++ b/locale/en/blog/vulnerability/february-2020-security-releases.md
@@ -41,21 +41,21 @@ Increase the strictness of HTTP header parsing. There are no known vulnerabiliti
--------------------------------------
-# Summary
+## Summary
The Node.js project will release new versions of all supported release lines on or shortly after Tuesday, February 4th, 2020.
One Critical severity and two High severity issues will be fixed. The release also includes stricter HTTP parsing.
-# Impact
+## Impact
All supported versions (10.x, 12.x, and 13.x) of Node.js are vulnerable.
-# Release timing
+## Release timing
Releases will be available at, or shortly after, Tuesday, February 4th, 2020.
-# Contact and future updates
+## Contact and future updates
The current Node.js security policy can be found at https://nodejs.org/en/security/. Please follow the process outlined in https://github.com/nodejs/node/blob/master/SECURITY.md if you wish to report a vulnerability in Node.js.
diff --git a/locale/en/blog/vulnerability/jan-2018-spectre-meltdown.md b/locale/en/blog/vulnerability/jan-2018-spectre-meltdown.md
index ba9bc6b554f40..7986b6acb0477 100644
--- a/locale/en/blog/vulnerability/jan-2018-spectre-meltdown.md
+++ b/locale/en/blog/vulnerability/jan-2018-spectre-meltdown.md
@@ -30,7 +30,7 @@ data that they should not have access to. In order to protect yourself
from these cases, apply the security patches for your operating
system. You do not need to update the Node.js runtime.
-# Contact and future updates
+## Contact and future updates
The current Node.js security policy can be found at https://nodejs.org/en/security/.
diff --git a/locale/en/blog/vulnerability/july-2017-security-releases.md b/locale/en/blog/vulnerability/july-2017-security-releases.md
index c764f8c1c3da8..e24b49dca3a6f 100644
--- a/locale/en/blog/vulnerability/july-2017-security-releases.md
+++ b/locale/en/blog/vulnerability/july-2017-security-releases.md
@@ -17,7 +17,7 @@ Expect a backport and update with the next release of 6.x
* [Node.js v8 (Current)](https://nodejs.org/en/blog/release/v8.3.0)
-# _(Update 11-July-2017)_ Security releases available
+## _(Update 11-July-2017)_ Security releases available
## Summary
Updates are now available for all active Node.js release lines as well as the 7.x line. These include the fix for the high severity vulnerability identified in the initial announcement, one additional lower priority Node.js vulnerability in the 4.x release line, as well as some lower priority fixes for Node.js dependencies across the current release lines.
@@ -79,7 +79,7 @@ The Node.js project will be releasing new versions across all of its active rele
## Denial of Service Vulnerability
All current versions of v4.x through to v8.x inclusive are vulnerable to an issue that can be used by an external attacker to cause a denial of service. The severity of this vulnerability is high and users of the affected versions should plan to upgrade when a fix is made available.
-# Impact
+## Impact
* Versions 4.x of Node.js **are vulnerable**
* Versions 6.x of Node.js **are vulnerable**
diff --git a/locale/en/blog/vulnerability/june-2018-security-releases.md b/locale/en/blog/vulnerability/june-2018-security-releases.md
index 4f0472f43e24b..8d73acfc77cbf 100644
--- a/locale/en/blog/vulnerability/june-2018-security-releases.md
+++ b/locale/en/blog/vulnerability/june-2018-security-releases.md
@@ -15,7 +15,7 @@ Updates are now available for all active Node.js release lines. These include th
We recommend that all users upgrade as soon as possible.
-# Downloads & release details
+## Downloads & release details
* [Node.js 10.4.1 (Current)](https://nodejs.org/en/blog/release/v10.4.1)
* [Node.js 9.11.2](https://nodejs.org/en/blog/release/v9.11.2)
diff --git a/locale/en/blog/vulnerability/oct-2017-dos.md b/locale/en/blog/vulnerability/oct-2017-dos.md
index cdc927475e64b..76920343eefd7 100644
--- a/locale/en/blog/vulnerability/oct-2017-dos.md
+++ b/locale/en/blog/vulnerability/oct-2017-dos.md
@@ -47,24 +47,24 @@ This vulnerability has been assigned CVE-2017-14919.
---
-# Summary
+## Summary
The Node.js project will be releasing new versions of 4.x, 6.x, and 8.x the week of the 24th of October to incorporate a security fix.
-# Denial of Service Vulnerability
+## Denial of Service Vulnerability
Versions 4.8.2 and later, 6.10.2 and later, as well as all versions of 8.x are vulnerable to an issue that can be used by an external attacker to cause a denial of service. The severity of this vulnerability is HIGH and users of the affected version should plan to upgrade when a fix is made available.
-# Impact
+## Impact
Versions 4.8.2 and later of Node.js are vulnerable.
Versions 6.10.2 and later of Node.js are vulnerable.
Versions 8.x of Node.js are vulnerable.
-# Release timing
+## Release timing
Releases will be available at, or shortly after, the 24th of October along with disclosure of the details for the vulnerability in order to allow for complete impact assessment by users.
-# Contact and future updates
+## Contact and future updates
The current Node.js security policy can be found at https://nodejs.org/en/security/.
diff --git a/locale/en/blog/vulnerability/september-2017-path-validation.md b/locale/en/blog/vulnerability/september-2017-path-validation.md
index 2d55e4a4e2dc2..dbf076f8a7b50 100644
--- a/locale/en/blog/vulnerability/september-2017-path-validation.md
+++ b/locale/en/blog/vulnerability/september-2017-path-validation.md
@@ -12,15 +12,15 @@ author: Michael Dawson
The Node.js project released a new version of 8.x this week which incorporates
a security fix.
-# Impact
+## Impact
Version 8.5.0 of Node.js is vulnerable.
4.x and 6.x versions are **NOT** vulnerable.
-# Downloads
+## Downloads
[Node.js 8 (Current)](https://nodejs.org/en/blog/release/v8.6.0/)
-# Node.js-specific security flaws
+## Node.js-specific security flaws
Node.js version 8.5.0 included a change which caused a security vulnerability
in the checks on paths made by some community modules. As a result, an
@@ -31,7 +31,7 @@ https://github.com/nodejs/node/commit/b98e8d995efb426bbdee56ce503017bdcbbc6332.
A CVE has been assigned as [CVE-2017-14849](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14849)
-# Contact and future updates
+## Contact and future updates
The current Node.js security policy can be found at https://nodejs.org/en/security/.
diff --git a/locale/en/blog/weekly-updates/weekly-update.2015-02-27.md b/locale/en/blog/weekly-updates/weekly-update.2015-02-27.md
index 7c1d1281caa0b..0a71061225c56 100644
--- a/locale/en/blog/weekly-updates/weekly-update.2015-02-27.md
+++ b/locale/en/blog/weekly-updates/weekly-update.2015-02-27.md
@@ -24,7 +24,7 @@ _Note: version **1.4.0** was tagged and built but not released. A libuv bug was
* [#7171](https://github.com/npm/npm/issues/7171) Warn that `engineStrict` in `package.json` will be going away in the next major version of npm (coming soon!)
* **libuv**: Upgrade to 1.4.2. See [libuv ChangeLog](https://github.com/libuv/libuv/blob/v1.x/ChangeLog) for details of fixes.
-# ARM offers support for io.js on ARMv8
+## ARM offers support for io.js on ARMv8
ARM contacted Rod Vagg, lead of the io.js Build Working Group, to offer their support to the io.js project. ARM and their hardware partners are on track to make ARMv8 a viable server platform and the nimble nature of server-side JavaScript make it a perfect fit to run on the new ARM.
@@ -34,7 +34,7 @@ From the beginning of the io.js project, Rod has championed the role of ARM for
The build team is in the process of being given access to the Linaro ARMv8 Server Cluster for integration with the io.js CI platform, which should eventually lead to regular ARMv8 binary releases.
-# Community Updates
+## Community Updates
* [**Reconciliation Proposal**](https://github.com/nodejs/node/issues/978): The io.js project is preparing a plan for reconciliation that can be brought to The Node.js Foundation. Input from the community is very important at this early stage so please leave a comment.
* **New internal C++ Streams API**: A [fresh C++ Streams API](https://github.com/nodejs/node/commit/b9686233fc0be679d7ba1262b611711629ee334e) landed in io.js this week, allowing you to wrap a TLS stream into another TLS stream.
@@ -47,7 +47,7 @@ The build team is in the process of being given access to the Linaro ARMv8 Serve
* **iojs-cn - New io.js Chinese Blog**: Similarly to the iojs-jp community, the iojs-cn community created a [localized blog](http://cn.iojs.org/) to publish posts about io.js to in their language. Make sure to visit if you're curious about iojs-cn or Chinese news about io.js!
* **[Roadmap Slides Review](https://www.youtube.com/watch?v=etI_UD4wXlo)** - A review of the roadmap slides before they were released to ensure they met with the message the project upholds.
-# io.js Support Added
+## io.js Support Added
* **[Wallaby.js](http://wallabyjs.com/)**, a while-you-write testing library for JavaScript, hit version 1.0 and [added support for io.js](http://dm.gl/2015/02/23/wallaby-version-one/)!
* **[jsdom](https://github.com/tmpvar/jsdom)**, an implementation of the WHATWG DOM and HTML standards, just hit [version 4.0.0](https://github.com/tmpvar/jsdom/blob/master/Changelog.md#400), which added a _requirement_ of io.js.
diff --git a/locale/en/blog/weekly-updates/weekly-update.2015-03-27.md b/locale/en/blog/weekly-updates/weekly-update.2015-03-27.md
index 118d9f90a5b93..9ba375ec1062d 100644
--- a/locale/en/blog/weekly-updates/weekly-update.2015-03-27.md
+++ b/locale/en/blog/weekly-updates/weekly-update.2015-03-27.md
@@ -28,13 +28,13 @@ This week we had one io.js releases [v1.6.2](https://iojs.org/dist/v1.6.2/), com
* `process.send()` is not synchronous as the docs suggest, a regression introduced in 1.0.2, see [#760](https://github.com/nodejs/node/issues/760) and fix in [#774](https://github.com/nodejs/node/issues/774)
* Calling `dns.setServers()` while a DNS query is in progress can cause the process to crash on a failed assertion [#894](https://github.com/nodejs/node/issues/894)
-# Community Updates
+## Community Updates
* Node.js Technical Governance Draft is proposed, you can check the draft [here](https://github.com/joyent/nodejs-advisory-board/pull/30)
* Microsoft Visual Studio team releases Node.js Tools 1.0 for Visual Studio, the release includes rich editor, code completions, interactive window, advanced debugging and profiling. Check [the announcement](http://blogs.msdn.com/b/visualstudio/archive/2015/03/25/node-js-tools-1-0-for-visual-studio.aspx).
* [SPM monitor supports Node.js and io.js](http://blog.sematext.com/2015/03/30/nodejs-iojs-monitoring/), the monitor adds performance monitoring, alerting, and anomaly detection.
-# Upcoming Events
+## Upcoming Events
* [NodeConf](http://nodeconf.com/) tickets are on sale, June 8th and 9th at Oakland, CA and NodeConf Adventure for June 11th - 14th at Walker Creek Ranch, CA
* [CascadiaJS](http://2015.cascadiajs.com/) tickets are on sale, July 8th - 10th at Washington State
diff --git a/locale/en/docs/guides/publishing-napi-modules.md b/locale/en/docs/guides/publishing-napi-modules.md
index 2fb8e90d8f674..40e56d587d7da 100644
--- a/locale/en/docs/guides/publishing-napi-modules.md
+++ b/locale/en/docs/guides/publishing-napi-modules.md
@@ -28,7 +28,7 @@ by default. The user will have to run `npm install iotivity-node@n-api` to
receive the N-API version. For more information on using tags with npm check
out ["Using dist-tags"][].
-# To introduce a dependency on an N-API version of a package
+## To introduce a dependency on an N-API version of a package
To add the N-API version of `iotivity-node` as a dependency, the `package.json`
will look like this:
diff --git a/locale/es/docs/guides/publishing-napi-modules.md b/locale/es/docs/guides/publishing-napi-modules.md
index d78432a4305db..e1a8318d32790 100644
--- a/locale/es/docs/guides/publishing-napi-modules.md
+++ b/locale/es/docs/guides/publishing-napi-modules.md
@@ -18,7 +18,7 @@ The following steps are illustrated using the package `iotivity-node`:
In this example, tagging the release with `n-api` has ensured that, although version 1.2.0-3 is later than the non-N-API published version (1.2.0-2), it will not be installed if someone chooses to install `iotivity-node` by simply running `npm install iotivity-node`. This will install the non-N-API version by default. The user will have to run `npm install iotivity-node@n-api` to receive the N-API version. For more information on using tags with npm check out ["Using dist-tags"](https://docs.npmjs.com/getting-started/using-tags).
-# To introduce a dependency on an N-API version of a package
+## To introduce a dependency on an N-API version of a package
To add the N-API version of `iotivity-node` as a dependency, the `package.json` will look like this:
diff --git a/locale/fr/docs/guides/publishing-napi-modules.md b/locale/fr/docs/guides/publishing-napi-modules.md
index d78432a4305db..e1a8318d32790 100644
--- a/locale/fr/docs/guides/publishing-napi-modules.md
+++ b/locale/fr/docs/guides/publishing-napi-modules.md
@@ -18,7 +18,7 @@ The following steps are illustrated using the package `iotivity-node`:
In this example, tagging the release with `n-api` has ensured that, although version 1.2.0-3 is later than the non-N-API published version (1.2.0-2), it will not be installed if someone chooses to install `iotivity-node` by simply running `npm install iotivity-node`. This will install the non-N-API version by default. The user will have to run `npm install iotivity-node@n-api` to receive the N-API version. For more information on using tags with npm check out ["Using dist-tags"](https://docs.npmjs.com/getting-started/using-tags).
-# To introduce a dependency on an N-API version of a package
+## To introduce a dependency on an N-API version of a package
To add the N-API version of `iotivity-node` as a dependency, the `package.json` will look like this:
diff --git a/locale/ro/docs/guides/publishing-napi-modules.md b/locale/ro/docs/guides/publishing-napi-modules.md
index d78432a4305db..e1a8318d32790 100644
--- a/locale/ro/docs/guides/publishing-napi-modules.md
+++ b/locale/ro/docs/guides/publishing-napi-modules.md
@@ -18,7 +18,7 @@ The following steps are illustrated using the package `iotivity-node`:
In this example, tagging the release with `n-api` has ensured that, although version 1.2.0-3 is later than the non-N-API published version (1.2.0-2), it will not be installed if someone chooses to install `iotivity-node` by simply running `npm install iotivity-node`. This will install the non-N-API version by default. The user will have to run `npm install iotivity-node@n-api` to receive the N-API version. For more information on using tags with npm check out ["Using dist-tags"](https://docs.npmjs.com/getting-started/using-tags).
-# To introduce a dependency on an N-API version of a package
+## To introduce a dependency on an N-API version of a package
To add the N-API version of `iotivity-node` as a dependency, the `package.json` will look like this:
diff --git a/locale/zh-cn/docs/guides/publishing-napi-modules.md b/locale/zh-cn/docs/guides/publishing-napi-modules.md
index 1d7ef112d7ed4..63cfac224caea 100644
--- a/locale/zh-cn/docs/guides/publishing-napi-modules.md
+++ b/locale/zh-cn/docs/guides/publishing-napi-modules.md
@@ -19,7 +19,7 @@ layout: docs.hbs
在这个例子中，标记为 `n-api` 的发布版已经确保尽管其版本 1.2.0-3 比 non-N-API 的版本号要延后一些，但如果有人简单通过运行 `npm install iotivity-node` 安装 `iotivity-node`，它不会被安装而只会默认安装 non-N-API。此人应该运行 `npm install iotivity-node@n-api` 得到 N-API 的版本号，有关使用标签的更多详情请查阅 ["使用目标标签"][]。
-# 在某个版本的 N-API 包中引入特定的依赖
+## 在某个版本的 N-API 包中引入特定的依赖
为了将 `iotivity-node` 的 N-API 版本作为依赖进行添加安装，`package.json` 应如下形式呈现：