Merge commit '8829fc4c2d240e7b7321d27001c2158251077b65' into replace-…

…github-links-to-relative

.all-contributorsrc

@@ -1505,6 +1505,15 @@
       "contributions": [
         "content"
       ]
+    },
+    {
+      "login": "breno404",
+      "name": "Breno Macedo",
+      "avatar_url": "https://avatars.githubusercontent.com/u/48841329?v=4",
+      "profile": "https://www.linkedin.com/in/breno-macedo-ernani-de-s%C3%A1-110223158/",
+      "contributions": [
+        "content"
+      ]
     }
   ],
   "projectName": "nodebestpractices",

README.brazilian-portuguese.md

@@ -554,7 +554,7 @@ Todas as declarações acima false se feitas com `===`.
 
 <br/><br/>
 
-## ![✔] 4.13 Teste seus 'middlewares' isolatdamente
+## ![✔] 4.13 Teste seus 'middlewares' isoladamente
 
 **TL;DR:** quando um 'middleware' contém alguma lógica imensa que abrange muitas solicitações, vale a pena testá-lo isoladamente, sem ativar todo o framework. Isso pode ser facilmente alcançado por 'stubbing' e espionando os objetos {req, res, next} 
 

README.md

@@ -9,7 +9,7 @@
 <br/>
 
 <div align="center">
-  <img src="https://img.shields.io/badge/⚙%20Item%20count%20-%20102%20Best%20Practices-blue.svg" alt="102 items"/> <img id="last-update-badge" src="https://img.shields.io/badge/%F0%9F%93%85%20Last%20update%20-%20July%2016%2C%202021-green.svg" alt="Last update: July 16, 2021" /> <img src="https://img.shields.io/badge/ %E2%9C%94%20Updated%20For%20Version%20-%20Node%2014.0.0-brightgreen.svg" alt="Updated for Node 14.0.0"/>
+  <img src="https://img.shields.io/badge/⚙%20Item%20count%20-%20102%20Best%20Practices-blue.svg" alt="102 items"/> <img id="last-update-badge" src="https://img.shields.io/badge/%F0%9F%93%85%20Last%20update%20-%20July%2021%2C%202021-green.svg" alt="Last update: July 21, 2021" /> <img src="https://img.shields.io/badge/ %E2%9C%94%20Updated%20For%20Version%20-%20Node%2014.0.0-brightgreen.svg" alt="Updated for Node 14.0.0"/>
 </div>
 
 <br/>
@@ -1595,6 +1595,7 @@ Thanks goes to these wonderful people who have contributed to this repository!
     <td align="center"><a href="https://github.com/vlad99902"><img src="https://avatars.githubusercontent.com/u/67615003?v=4?s=100" width="100px;" alt=""/><br /><sub><b>Vladislav Legkov</b></sub></a><br /><a href="#content-vlad99902" title="Content">🖋</a></td>
     <td align="center"><a href="http://kerolloz.github.io"><img src="https://avatars.githubusercontent.com/u/36763164?v=4?s=100" width="100px;" alt=""/><br /><sub><b>Kerollos Magdy</b></sub></a><br /><a href="#content-kerolloz" title="Content">🖋</a></td>
     <td align="center"><a href="https://www.linkedin.com/in/erez-lieberman-b90b7219/"><img src="https://avatars.githubusercontent.com/u/3277260?v=4?s=100" width="100px;" alt=""/><br /><sub><b>Erez Lieberman</b></sub></a><br /><a href="#content-erezLieberman" title="Content">🖋</a></td>
+    <td align="center"><a href="https://www.linkedin.com/in/breno-macedo-ernani-de-s%C3%A1-110223158/"><img src="https://avatars.githubusercontent.com/u/48841329?v=4?s=100" width="100px;" alt=""/><br /><sub><b>Breno Macedo</b></sub></a><br /><a href="#content-breno404" title="Content">🖋</a></td>
   </tr>
 </table>
 

sections/docker/clean-cache.chinese.md

@@ -0,0 +1,27 @@
+# 清除NODE_MODULE缓存
+
+<br/><br/>
+
+### 一段解释
+
+node包管理器，npm和Yarn，会本地缓存安装过的包，以便在未来的项目中，如果需要同样的包，就不需要从远程仓库重新获取。尽管这会导致包的重复，消耗更多的存储 - 作为回报，它维持了一个安装相同包的本地开发环境。而在Docker容器中，这种存储是没什么价值的，因为它仅仅安装依赖一次。通过移除这类缓存，只需要使用一行代码，上十MB的存储会从image中移除。当这样做的时候，确保它不会通过非零（non-zero）码退出，因而由于缓存问题导致CI构建失败 - 这可以通过添加一个force标志位来避免。
+
+*请注意如果您使用multi-stage构建，只要您在最后阶段不安装新的包，清除缓存是没意义的*
+
+<br/><br/>
+
+### 代码示例 - 清除缓存
+
+<details>
+<summary><strong>Dockerfile</strong></summary>
+
+```dockerfile
+FROM node:12-slim AS build
+WORKDIR /usr/src/app
+COPY package.json package-lock.json ./
+RUN npm ci --production && npm cache clean --force
+
+# 剩余部分
+```
+
+</details>

sections/docker/docker-ignore.chinese.md

@@ -0,0 +1,50 @@
+# 使用.dockerignore防止泄漏机密
+
+<br/><br/>
+
+### 一段解释
+
+Docker的build命令会通过一个虚拟网络（virtual network）拷贝本地文件到构建的上下文环境。注意 - 开发和CI文件夹会包含机密文件，比如.npmrc，.aws，.env，以及其他一些敏感文件。最终，Docker镜像可能会包含机密信息，并在不安全的区域暴露它们（例如，Docker repository，partners servers）。一个更好的方式是，Dockerfile应该明确地描述哪些文件需要被复制。除此之外，包含一个.dockerginore文件，还充当最后一个安全网，过滤掉不必要的文件夹和潜在的机密文件。这样做还可以加快构建速度 - 通过排除在生产环境并不会用到的通用开发文件夹（例如.git，测试结果，IDE配置），整个构建过程可以更好的使用缓存，并取得一个更佳的性能。
+
+<br/><br/>
+
+### 代码示例 – 对于Node.js，一个好的默认.dockerignore示例
+
+<details>
+<summary><strong>.dockerignore</strong></summary>
+
+```
+**/node_modules/
+**/.git
+**/README.md
+**/LICENSE
+**/.vscode
+**/npm-debug.log
+**/coverage
+**/.env
+**/.editorconfig
+**/.aws
+**/dist
+```
+
+</details>
+
+<br/><br/>
+
+### 代码示例 反模式 - 遍历拷贝所有文件
+
+<details>
+<summary><strong>Dockerfile</strong></summary>
+
+```dockerfile
+FROM node:12-slim AS build
+
+WORKDIR /usr/src/app
+# 下一行拷贝所有文件
+COPY . .
+
+# 剩余部分
+
+```
+
+</details>

sections/docker/generic-tips.chinese.md

@@ -0,0 +1,29 @@
+[✔]: ../../assets/images/checkbox-small-blue.png
+
+# 通用的Node.js Docker最佳实践
+
+此通用Docker指南部分包含所有编程语言中标准化的最佳实践，并没有针对Node.js的特殊解释
+
+## ![✔] 使用命令COPY优于ADD
+
+**TL;DR:** COPY更安全，因为它只复制本地文件，而ADD支持更高级的获取，比如从远程站点下载二进制文件
+
+## ![✔] 避免更新基础OS
+
+**TL;DR:** 在构建期间更新本地二进制文件（例如apt get update）会在每次运行时创建不一致的映像，并且还需要提升权限。取而代之，使用经常更新的基础镜像
+
+## ![✔] 使用标签对镜像分类
+
+**TL;DR:** 为每个镜像提供元数据（metadata）可能有助于Ops专业人员充分处理它。例如，包括维护人员姓名、构建日期和其他信息，当有人需要对映像进行推理时，这些信息可能会被证明是有用的
+
+## ![✔] 使用非特权容器
+
+**TL;DR:** 特权容器具有与主机上的根用户相同的权限和功能。这是很少需要的，作为一个经验法则，应该使用在官方Node镜像中创建的'node'用户
+
+## ![✔] 检查并验证最终结果
+
+**TL;DR:** 有时很容易忽略构建过程中的副作用，如泄露的秘密或不必要的文件。使用[Dive](https://github.com/wagoodman/dive)等工具检查生成的镜像可以很容易地帮助识别此类问题
+
+## ![✔] 执行完整性检查
+
+**TL;DR:** 在拉取基本镜像或最终镜像时，网络可能会被误导并重定向到下载恶意镜像。除非对内容进行签名和验证，否则标准Docker协议中没有任何内容可以防止这种情况。[Docker Notary](https://docs.docker.com/notary/getting_started/)是一个可以执行此类检查的工具

sections/errorhandling/operationalvsprogrammererror.md

@@ -80,6 +80,6 @@ From the blog, debugable.com ranked 3 for the keywords “Node.js uncaught excep
 From the blog: JS Recipes
 
 > …There are primarily three schools of thoughts on error handling:
-1. Let the application crash and restart it.
-2. Handle all possible errors and never crash.
-3. A balanced approach between the two
+>1. Let the application crash and restart it.
+>2. Handle all possible errors and never crash.
+>3. A balanced approach between the two