fix: remark-lint-no-multiple-toplevel-headings (nodejs#3121)

Co-authored-by: Rich Trott <[email protected]>

.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],

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

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

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,15 +61,15 @@ 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
 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

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.
 

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.
 

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/.
 

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**

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)

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.<br>
 Versions 6.10.2 and later of Node.js are vulnerable.<br>
 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/.
 

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/.
 

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.

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

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: