fix: no-shortcut-reference-link

.remarkrc

@@ -7,7 +7,6 @@
     ["remark-lint-maximum-line-length", false],
     ["remark-lint-no-file-name-articles", false],
     ["remark-lint-no-literal-urls", false],
-    ["remark-lint-no-shortcut-reference-link", false],
     ["remark-lint-no-trailing-spaces", false],
     ["remark-lint-no-undefined-references", false],
     ["remark-lint-no-unused-definitions", false],

locale/ar/get-involved/node-meetups.md

@@ -329,7 +329,7 @@ layout: contribute.hbs
 
 ##### إرفين
 
-* [اللقاء]https://www.meetup.com/Node-JS-OC/)
+* [اللقاء](https://www.meetup.com/Node-JS-OC/)
 * تردد اللقاء - شهريا
 * كيف تقدم طلب محاضرة ؟ اتصل بالمنظمين في صفحة اللقاءات.
 * المنظم - فرشيد عاطف

locale/en/blog/feature/streams2.md

@@ -196,7 +196,7 @@ Note that `stream.Readable` is an abstract class designed to be
 extended with an underlying implementation of the `_read(size)`
 method. (See below.)
 
-### new stream.Readable([options])
+### new stream.Readable(\[options\])
 
 * `options` {Object}
   * `highWaterMark` {Number} The maximum number of bytes to store in
@@ -458,7 +458,7 @@ can be `'utf8'`, `'utf16le'` (`'ucs2'`), `'ascii'`, or `'hex'`.
 The encoding can also be set by specifying an `encoding` field to the
 constructor.
 
-### readable.read([size])
+### readable.read(\[size\])
 
 * `size` {Number | null} Optional number of bytes to read.
 * Return: {Buffer | String | null}
@@ -479,7 +479,7 @@ a future `'readable'` event will be emitted when more is available.
 Calling `stream.read(0)` will always return `null`, and will trigger a
 refresh of the internal buffer, but otherwise be a no-op.
 
-### readable.pipe(destination, [options])
+### readable.pipe(destination, \[options\])
 
 * `destination` {Writable Stream}
 * `options` {Object} Optional
@@ -515,7 +515,7 @@ reader.on("end", function() {
 Note that `process.stderr` and `process.stdout` are never closed until
 the process exits, regardless of the specified options.
 
-### readable.unpipe([destination])
+### readable.unpipe(\[destination\])
 
 * `destination` {Writable Stream} Optional
 
@@ -549,7 +549,7 @@ Note that `stream.Writable` is an abstract class designed to be
 extended with an underlying implementation of the
 `_write(chunk, encoding, cb)` method. (See below.)
 
-### new stream.Writable([options])
+### new stream.Writable(\[options\])
 
 * `options` {Object}
   * `highWaterMark` {Number} Buffer level when `write()` starts
@@ -595,7 +595,7 @@ the class that defines it, and should not be called directly by user
 programs. However, you **are** expected to override this method in
 your own extension classes.
 
-### writable.write(chunk, [encoding], [callback])
+### writable.write(chunk, \[encoding\], \[callback\])
 
 * `chunk` {Buffer | String} Data to be written
 * `encoding` {String} Optional. If `chunk` is a string, then encoding
@@ -612,7 +612,7 @@ the buffer is full, and the data will be sent out in the future. The
 The specifics of when `write()` will return false, is determined by
 the `highWaterMark` option provided to the constructor.
 
-### writable.end([chunk], [encoding], [callback])
+### writable.end(\[chunk\], \[encoding\], \[callback\])
 
 * `chunk` {Buffer | String} Optional final data to be written
 * `encoding` {String} Optional. If `chunk` is a string, then encoding
@@ -698,7 +698,7 @@ Rather than implement the `_read()` and `_write()` methods, Transform
 classes must implement the `_transform()` method, and may optionally
 also implement the `_flush()` method. (See below.)
 
-### new stream.Transform([options])
+### new stream.Transform(\[options\])
 
 * `options` {Object} Passed to both Writable and Readable
   constructors.

locale/en/blog/release/v0.10.42.md

@@ -7,6 +7,10 @@ slug: node-v0-10-42
 layout: blog-post.hbs
 author: James M Snell
 ---
+<!--lint disable prohibited-strings-->
+<!--lint disable maximum-line-length-->
+<!--lint disable no-literal-urls-->
+<!--lint disable no-shortcut-reference-link-->
 
 This is an important security release. For full details see https://nodejs.org/en/blog/vulnerability/february-2016-security-releases/ for details on patched vulnerabilities.
 

locale/en/blog/release/v0.10.44.md

@@ -7,6 +7,10 @@ slug: node-v0-10-44
 layout: blog-post.hbs
 author: Rod Vagg
 ---
+<!--lint disable prohibited-strings-->
+<!--lint disable maximum-line-length-->
+<!--lint disable no-literal-urls-->
+<!--lint disable no-shortcut-reference-link-->
 
 **This is a security release**, upgrading the bundled version of npm due to a credentials leak vulnerability. Further information can be found in our post: https://nodejs.org/en/blog/vulnerability/npm-tokens-leak-march-2016/
 

locale/en/blog/release/v0.10.45.md

@@ -7,6 +7,10 @@ slug: node-v0-10-45
 layout: blog-post.hbs
 author: Rod Vagg
 ---
+<!--lint disable prohibited-strings-->
+<!--lint disable maximum-line-length-->
+<!--lint disable no-literal-urls-->
+<!--lint disable no-shortcut-reference-link-->
 
 ### Notable changes:
 

locale/en/blog/release/v0.10.46.md

@@ -7,6 +7,10 @@ slug: node-v0-10-46
 layout: blog-post.hbs
 author: Rod Vagg
 ---
+<!--lint disable prohibited-strings-->
+<!--lint disable maximum-line-length-->
+<!--lint disable no-literal-urls-->
+<!--lint disable no-shortcut-reference-link-->
 
 ### Notable changes:
 

locale/en/blog/release/v0.10.47.md

@@ -7,6 +7,10 @@ slug: node-v0-10-47
 layout: blog-post.hbs
 author: Rod Vagg
 ---
+<!--lint disable prohibited-strings-->
+<!--lint disable maximum-line-length-->
+<!--lint disable no-literal-urls-->
+<!--lint disable no-shortcut-reference-link-->
 
 **This is an important security release**. All Node.js users should consult the [security release summary](https://nodejs.org/en/blog/vulnerability/september-2016-security-releases/) at for details on patched vulnerabilities.
 

locale/en/blog/release/v0.10.48.md

@@ -7,6 +7,10 @@ slug: node-v0-10-48
 layout: blog-post.hbs
 author: Rod Vagg
 ---
+<!--lint disable prohibited-strings-->
+<!--lint disable maximum-line-length-->
+<!--lint disable no-literal-urls-->
+<!--lint disable no-shortcut-reference-link-->
 
 This is a security release. All Node.js users should consult the security release summary at https://nodejs.org/en/blog/vulnerability/october-2016-security-releases/ for details on patched vulnerabilities.
 

locale/en/blog/release/v0.11.0.md

@@ -6,6 +6,10 @@ title: Node v0.11.0 (Unstable)
 slug: node-v0-11-0-stable
 layout: blog-post.hbs
 ---
+<!--lint disable prohibited-strings-->
+<!--lint disable maximum-line-length-->
+<!--lint disable no-literal-urls-->
+<!--lint disable no-shortcut-reference-link-->
 
 2013.03.28, Version 0.11.0 (Unstable)
 

locale/en/blog/release/v0.11.11.md

@@ -6,6 +6,10 @@ title: Node v0.11.11 (Unstable)
 slug: node-v0-11-11-unstable
 layout: blog-post.hbs
 ---
+<!--lint disable prohibited-strings-->
+<!--lint disable maximum-line-length-->
+<!--lint disable no-literal-urls-->
+<!--lint disable no-shortcut-reference-link-->
 
 2014.01.29, Version 0.11.11 (Unstable)
 

locale/en/blog/release/v0.12.10.md

@@ -7,6 +7,10 @@ slug: node-v0-12-10
 layout: blog-post.hbs
 author: James M Snell
 ---
+<!--lint disable prohibited-strings-->
+<!--lint disable maximum-line-length-->
+<!--lint disable no-literal-urls-->
+<!--lint disable no-shortcut-reference-link-->
 
 This is an important security release. For full details see https://nodejs.org/en/blog/vulnerability/february-2016-security-releases/ for details on patched vulnerabilities.
 

locale/en/blog/release/v0.12.13.md

@@ -7,6 +7,10 @@ slug: node-v0-12-13
 layout: blog-post.hbs
 author: Rod Vagg
 ---
+<!--lint disable prohibited-strings-->
+<!--lint disable maximum-line-length-->
+<!--lint disable no-literal-urls-->
+<!--lint disable no-shortcut-reference-link-->
 
 **This is a security release**, upgrading the bundled version of npm due to a credentials leak vulnerability. Further information can be found in our post: https://nodejs.org/en/blog/vulnerability/npm-tokens-leak-march-2016/
 

locale/en/blog/release/v0.12.15.md

@@ -7,6 +7,10 @@ slug: node-v0-12-15
 layout: blog-post.hbs
 author: Rod Vagg
 ---
+<!--lint disable prohibited-strings-->
+<!--lint disable maximum-line-length-->
+<!--lint disable no-literal-urls-->
+<!--lint disable no-shortcut-reference-link-->
 
 ### Notable changes:
 

locale/en/blog/release/v0.12.16.md

@@ -7,6 +7,10 @@ slug: node-v0-12-16
 layout: blog-post.hbs
 author: Rod Vagg
 ---
+<!--lint disable prohibited-strings-->
+<!--lint disable maximum-line-length-->
+<!--lint disable no-literal-urls-->
+<!--lint disable no-shortcut-reference-link-->
 
 **This is an important security release**. All Node.js users should consult the [security release summary](https://nodejs.org/en/blog/vulnerability/september-2016-security-releases/) at for details on patched vulnerabilities.
 

locale/en/blog/release/v0.12.17.md

@@ -7,6 +7,10 @@ slug: node-v0-12-17
 layout: blog-post.hbs
 author: Rod Vagg
 ---
+<!--lint disable prohibited-strings-->
+<!--lint disable maximum-line-length-->
+<!--lint disable no-literal-urls-->
+<!--lint disable no-shortcut-reference-link-->
 
 This is a security release. All Node.js users should consult the security release summary at https://nodejs.org/en/blog/vulnerability/october-2016-security-releases/ for details on patched vulnerabilities.
 

locale/en/blog/release/v0.12.18.md

@@ -7,6 +7,10 @@ slug: node-v0-12-18
 layout: blog-post.hbs
 author: Rod Vagg
 ---
+<!--lint disable prohibited-strings-->
+<!--lint disable maximum-line-length-->
+<!--lint disable no-literal-urls-->
+<!--lint disable no-shortcut-reference-link-->
 
 **Please be aware that this will likely be the final official release of the 0.12 release line. As per our [LTS schedule](https://github.com/nodejs/LTS/#lts-schedule), support for 0.12 ends on December 31st 2016. Please plan your migration to a newer, supported release line.**
 

locale/en/blog/release/v0.8.6.md

@@ -6,6 +6,10 @@ slug: node-v0-8-6-stable
 date: 2012-08-07T19:03:55.905Z
 layout: blog-post.hbs
 ---
+<!--lint disable prohibited-strings-->
+<!--lint disable maximum-line-length-->
+<!--lint disable no-literal-urls-->
+<!--lint disable no-shortcut-reference-link-->
 
 2012.08.07, Version 0.8.6 (Stable)
 

locale/en/blog/release/v4.2.1.md

@@ -6,6 +6,10 @@ title: Node v4.2.1 (LTS)
 slug: node-v4-2-1-lts
 layout: blog-post.hbs
 ---
+<!--lint disable prohibited-strings-->
+<!--lint disable maximum-line-length-->
+<!--lint disable no-literal-urls-->
+<!--lint disable no-shortcut-reference-link-->
 
 ### Notable changes
 

locale/en/docs/guides/simple-profiling.md

@@ -157,7 +157,7 @@ up by language. First, we look at the summary section and see:
 This tells us that 97% of all samples gathered occurred in C++ code and that
 when viewing other sections of the processed output we should pay most attention
 to work being done in C++ (as opposed to JavaScript). With this in mind, we next
-find the [C++] section which contains information about which C++ functions are
+find the \[C++\] section which contains information about which C++ functions are
 taking the most CPU time and see:
 
 ```
@@ -174,7 +174,7 @@ taken up by a function called PBKDF2 which corresponds to our hash generation
 from a user's password. However, it may not be immediately obvious how the lower
 two entries factor into our application (or if it is we will pretend otherwise
 for the sake of example). To better understand the relationship between these
-functions, we will next look at the [Bottom up (heavy) profile] section which
+functions, we will next look at the \[Bottom up (heavy) profile\] section which
 provides information about the primary callers of each function. Examining this
 section, we find:
 

locale/en/get-involved/node-meetups.md

@@ -356,7 +356,7 @@ REQUIREMENTS
 * Frequency of meetups - every 6-9 month
 * How to submit a talk? Contact organizers in the meetup page or use contacts information below
 * Organizer name - Denis Izmaylov
-* Organizer contact info - [Telegram](https://t.me/DenisIzmaylov) [Twitter](https://twitter.com/DenisIzmaylov] [Facebook](https://facebook.com/denis.izmaylov)
+* Organizer contact info - [Telegram](https://t.me/DenisIzmaylov) [Twitter](https://twitter.com/DenisIzmaylov) [Facebook](https://facebook.com/denis.izmaylov)
 
 ### South Africa
 

locale/es/docs/guides/simple-profiling.md

@@ -129,7 +129,7 @@ Opening processed.txt in your favorite text editor will give you a few different
     215    0.6%          Unaccounted
 ```
 
-This tells us that 97% of all samples gathered occurred in C++ code and that when viewing other sections of the processed output we should pay most attention to work being done in C++ (as opposed to JavaScript). With this in mind, we next find the [C++] section which contains information about which C++ functions are taking the most CPU time and see:
+This tells us that 97% of all samples gathered occurred in C++ code and that when viewing other sections of the processed output we should pay most attention to work being done in C++ (as opposed to JavaScript). With this in mind, we next find the \[C++\] section which contains information about which C++ functions are taking the most CPU time and see:
 
 ```
  [C++]:
@@ -139,7 +139,7 @@ This tells us that 97% of all samples gathered occurred in C++ code and that whe
    3165    8.4%    8.6%  _malloc_zone_malloc
 ```
 
-We see that the top 3 entries account for 72.1% of CPU time taken by the program. From this output, we immediately see that at least 51.8% of CPU time is taken up by a function called PBKDF2 which corresponds to our hash generation from a user's password. However, it may not be immediately obvious how the lower two entries factor into our application (or if it is we will pretend otherwise for the sake of example). To better understand the relationship between these functions, we will next look at the [Bottom up (heavy) profile] section which provides information about the primary callers of each function. Examining this section, we find:
+We see that the top 3 entries account for 72.1% of CPU time taken by the program. From this output, we immediately see that at least 51.8% of CPU time is taken up by a function called PBKDF2 which corresponds to our hash generation from a user's password. However, it may not be immediately obvious how the lower two entries factor into our application (or if it is we will pretend otherwise for the sake of example). To better understand the relationship between these functions, we will next look at the \[Bottom up (heavy) profile\] section which provides information about the primary callers of each function. Examining this section, we find:
 
 ```
    ticks parent  name

locale/fr/docs/guides/simple-profiling.md

@@ -129,7 +129,7 @@ Opening processed.txt in your favorite text editor will give you a few different
     215    0.6%          Unaccounted
 ```
 
-This tells us that 97% of all samples gathered occurred in C++ code and that when viewing other sections of the processed output we should pay most attention to work being done in C++ (as opposed to JavaScript). With this in mind, we next find the [C++] section which contains information about which C++ functions are taking the most CPU time and see:
+This tells us that 97% of all samples gathered occurred in C++ code and that when viewing other sections of the processed output we should pay most attention to work being done in C++ (as opposed to JavaScript). With this in mind, we next find the \[C++\] section which contains information about which C++ functions are taking the most CPU time and see:
 
 ```
  [C++]:
@@ -139,7 +139,7 @@ This tells us that 97% of all samples gathered occurred in C++ code and that whe
    3165    8.4%    8.6%  _malloc_zone_malloc
 ```
 
-We see that the top 3 entries account for 72.1% of CPU time taken by the program. From this output, we immediately see that at least 51.8% of CPU time is taken up by a function called PBKDF2 which corresponds to our hash generation from a user's password. However, it may not be immediately obvious how the lower two entries factor into our application (or if it is we will pretend otherwise for the sake of example). To better understand the relationship between these functions, we will next look at the [Bottom up (heavy) profile] section which provides information about the primary callers of each function. Examining this section, we find:
+We see that the top 3 entries account for 72.1% of CPU time taken by the program. From this output, we immediately see that at least 51.8% of CPU time is taken up by a function called PBKDF2 which corresponds to our hash generation from a user's password. However, it may not be immediately obvious how the lower two entries factor into our application (or if it is we will pretend otherwise for the sake of example). To better understand the relationship between these functions, we will next look at the \[Bottom up (heavy) profile\] section which provides information about the primary callers of each function. Examining this section, we find:
 
 ```
    ticks parent  name

locale/it/about/community.md

@@ -21,7 +21,7 @@ Ci sono quattro tipi di coinvolgimenti con il Comitato della Community:
 * Un **Osservatore** è un individuo che ha richiesto o a cui è stato richiesto di assistere ad un incontro del CommComm. È anche il primo step per diventare un Membro.
 * Un **Membro** è un collaboratore con diritti di voto che ha soddisfatto i requisiti di partecipazione ed è stato eletto dalla procedura di votazione del CommComm.
 
-Per la lista attuale dei membri del Comitato della Community, vedere il [README.md] del progetto (https://github.com/nodejs/community-committee).
+Per la lista attuale dei membri del Comitato della Community, vedere il [README.md del progetto](https://github.com/nodejs/community-committee).
 
 ## Contributors and Collaborators (Contributori e Collaboratori)
 

locale/ja/docs/guides/simple-profiling.md

@@ -233,15 +233,15 @@ up by language. First, we look at the summary section and see:
 This tells us that 97% of all samples gathered occurred in C++ code and that
 when viewing other sections of the processed output we should pay most attention
 to work being done in C++ (as opposed to JavaScript). With this in mind, we next
-find the [C++] section which contains information about which C++ functions are
+find the \[C++\] section which contains information about which C++ functions are
 taking the most CPU time and see:
 
 -->
 これは、収集されたすべてのサンプルの 97％ が C++ コードで発生しており、
 処理された出力の他のセクションを見るときは
 (JavaScript ではなく) C++ で行われている作業に最も注意する必要があることを示しています。
 これを念頭に置いて、次にどの C++ 関数が最も CPU 時間を消費しているかについての情報を含む
-[C++] セクションを見てみます。
+\[C++\] セクションを見てみます。
 
 ```
  [C++]:
@@ -258,7 +258,7 @@ taken up by a function called PBKDF2 which corresponds to our hash generation
 from a user's password. However, it may not be immediately obvious how the lower
 two entries factor into our application (or if it is we will pretend otherwise
 for the sake of example). To better understand the relationship between these
-functions, we will next look at the [Bottom up (heavy) profile] section which
+functions, we will next look at the \[Bottom up (heavy) profile\] section which
 provides information about the primary callers of each function. Examining this
 section, we find:
 
@@ -270,7 +270,7 @@ CPU 時間の少なくとも 51.8％ が占められていることが分かり
 (またはそうである場合は例のために別のふりをすることになる)、
 すぐには明らかにならないかもしれません。
 これらの関数間の関係をよりよく理解するために、
-次に各関数の主な呼び出し元に関する情報を提供する [Bottom up (heavy) profile] セクションを見ていきます。
+次に各関数の主な呼び出し元に関する情報を提供する \[Bottom up (heavy) profile\] セクションを見ていきます。
 このセクションを調べると、次のことがわかります。
 
 ```