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/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\] セクションを見ていきます。
 このセクションを調べると、次のことがわかります。
 
 ```

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

@@ -315,7 +315,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:
 
 ```
@@ -329,7 +329,7 @@ taking the most CPU time and see:
 
 이 부분을 보면 C++ 코드에서 수집된 샘플이 97%를 차지하는 것을 볼 수 있으므로 처리된 결과에서
 다른 부분을 볼 때 C++에서 이뤄진 작업에 대부분의 관심을 기울여야 합니다.(JavaScript 대비)
-그래서 C++ 함수가 대부분의 CPU 시간을 차지한 정보를 담고 있는 [C++] 부분을 찾아볼 것입니다.
+그래서 C++ 함수가 대부분의 CPU 시간을 차지한 정보를 담고 있는 \[C++\] 부분을 찾아볼 것입니다.
 
 ```
  [C++]:
@@ -346,7 +346,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:
 
@@ -370,7 +370,7 @@ section, we find:
 해시를 생성하는 PBKDF2 함수 호출이 최소 51.8%의 CPU 시간을 차지한 것을 바로 눈치챌 수 있습니다.
 하지만 더 낮은 비율을 가진 두 부분은 애플리케이션의 어떤 부분인지 바로 알 수 없습니다.(아니면
 예제를 위해서 그런 척 할 것입니다.) 이러한 함수 간의 관계를 더 이해하려면 각 함수의 주요 호출자 정보를
-제공하는 [Bottom up (heavy) profile] 부분을 봐야 합니다.
+제공하는 \[Bottom up (heavy) profile\] 부분을 봐야 합니다.
 이 부분을 찾아보면 다음과 같이 나와 있습니다.
 
 ```

locale/pt-br/blog/community/transitions.md

@@ -8,8 +8,7 @@ slug: transitions
 layout: blog-post.hbs
 ---
 
-Em Fevereiro, nós anunciamos a [Fundação Node.js]
-(https://www.joyent.com/blog/introducing-the-nodejs-foundation),
+Em Fevereiro, nós anunciamos a [Fundação Node.js](https://www.joyent.com/blog/introducing-the-nodejs-foundation),
 que irá administrar o futuro do Node.js e abri-lo para a
 comunidade de uma maneira que não estava disponível antes. Organizações como
 IBM, SAP, Apigee, F5, Fidelity, Microsoft, PayPal, Red Hat, e outras estão

locale/pt-br/docs/guides/dont-block-the-event-loop.md

@@ -102,7 +102,7 @@ Você nunca deve bloquear o Event Loop.
 Em outras palavras, cada um de seus callbacks JavaScript devem ser concluídos rapidamente.
 Isto, obviamente, também se aplica aos seus `wait`'s , seus `Promise.then`'s, e assim por diante.
 
-Uma boa maneira de garantir isso é estudar sobre a ["complexidade computacional"] (https://en.wikipedia.org/wiki/Time_complexity) de seus callbacks.
+Uma boa maneira de garantir isso é estudar sobre a ["complexidade computacional"](https://en.wikipedia.org/wiki/Time_complexity) de seus callbacks.
 Se o seu callback executar um número constante de etapas, independentemente de seus argumentos, você sempre dará a cada cliente pendente uma chance justa.
 Se seu callback executa um número considerável de etapas, dependendo de seus argumentos, pense em quanto tempo os argumentos podem demorar.
 
@@ -241,7 +241,7 @@ Em um servidor, *você não deve usar as seguintes APIs síncronas desses módul
   * `zlib.inflateSync`
   * `zlib.deflateSync`
 * Sistema de arquivo:
-  * Não use as APIs do sistema de arquivos síncronas. Por exemplo, se o arquivo que você acessar estiver em um [sistema de arquivos distribuído](https://en.wikipedia.org/wiki/Clustered_file_system#Distributed_file_systems) como [NFS](https://en.wikipedia.org/wiki/ Network_File_System), os tempos de acesso podem variar bastante.
+  * Não use as APIs do sistema de arquivos síncronas. Por exemplo, se o arquivo que você acessar estiver em um [sistema de arquivos distribuído](https://en.wikipedia.org/wiki/Clustered_file_system#Distributed_file_systems) como [NFS](https://en.wikipedia.org/wiki/Network_File_System), os tempos de acesso podem variar bastante.
 * Child process:
   * `child_process.spawnSync`
   * `child_process.execSync`
@@ -348,7 +348,7 @@ Para uma tarefa complicada, mova o trabalho do Event Loop para uma Worker Pool.
 ##### Como fazer offload
 Você tem duas opções para uma Work Pool de destino no qual descarregar o trabalho.
 
-1. Você pode usar a Worker Pool built-in do Node desenvolvendo um [addon C++](https://nodejs.org/api/addons.html). Nas versões mais antigas do Node, crie seu complemento C++ usando [NAN](https://github.com/nodejs/nan) e nas versões mais recentes use [N-API](https://nodejs.org/api/n -api.html). [node-webworker-threads](https://www.npmjs.com/package/webworker-threads) oferece uma maneira JavaScript-only para acessar a Worker Pool do Node.
+1. Você pode usar a Worker Pool built-in do Node desenvolvendo um [addon C++](https://nodejs.org/api/addons.html). Nas versões mais antigas do Node, crie seu complemento C++ usando [NAN](https://github.com/nodejs/nan) e nas versões mais recentes use [N-API](https://nodejs.org/api/n-api.html). [node-webworker-threads](https://www.npmjs.com/package/webworker-threads) oferece uma maneira JavaScript-only para acessar a Worker Pool do Node.
 2. Você pode criar e gerenciar sua própria Worker Pool dedicada à computação, em vez da Worker Pool de I/O do Node. As maneiras mais simples de fazer isso são usando [Child Process](https://nodejs.org/api/child_process.html) ou [Cluster](https://nodejs.org/api/cluster.html).
 
 Você *não* deve simplesmente criar um [Child Process](https://nodejs.org/api/child_process.html) para cada cliente.