[pt-br] translating tsconfig-reference options files, related to module resolution

packages/tsconfig-reference/copy/en/options/types.md

@@ -12,12 +12,12 @@ If `types` is specified, only packages listed will be included in the global sco
 ```json
 {
   "compilerOptions": {
-    "types": ["node", "jest", "lodash"]
+    "types": ["node", "jest", "express"]
   }
 }
 ```
 
-This `tsconfig.json` file will _only_ include `./node_modules/@types/node`, `./node_modules/@types/lodash` and `./node_modules/@types/express`.
+This `tsconfig.json` file will _only_ include `./node_modules/@types/node`, `./node_modules/@types/jest` and `./node_modules/@types/express`.
 Other packages under `node_modules/@types/*` will not be included.
 
 ### What does this affect?

packages/tsconfig-reference/copy/pt/options/esModuleInterop.md

@@ -0,0 +1,43 @@
+---
+display: "Interoperabilidade de Módulo ES"
+oneline: "Emite JS adicional para dar suporte ao importar módulos commonjs"
+---
+
+Permite interoperabilidade de emição entre Módulos CommonJS e ES através da criação de objetos namespace para todas as importações.
+
+TypeScript adere ao padrão EcmaScript para módulos, o que significa que um arquivo com exportações teria que especificamente
+incluir uma exportação `default` para dar suporte à sintaxes como `import React from "react"`.
+Este padrão de exportação é raro em módulos para CommonJS. Por exemplo, sem `esModuleInterop` como true:
+
+```ts twoslash
+// @checkJs
+// @allowJs
+// @allowSyntheticDefaultImports
+// @filename: utilFunctions.js
+// @noImplicitAny: false
+const getStringLength = (str) => str.length;
+
+module.exports = {
+  getStringLength,
+};
+
+// @filename: index.ts
+import utils from "./utilFunctions";
+
+const count = utils.getStringLength("Check JS");
+```
+
+Isto não vai funcionar porque não existe um objeto `default` o qual você pode importar. Apesar de parecer que deveria.
+Por conveniência, transpiladores como Babel vão criar um default automaticamente se não encontrarem um existente. Fazendo com que o módulo se pareça um pouco mais com isto:
+
+```js
+// @filename: utilFunctions.js
+const getStringLength = (str) => str.length;
+const allFunctions = {
+  getStringLength,
+};
+
+module.exports = allFunctions;
+```
+
+Ativando esta flag no compilador também vai habilitar [`allowSyntheticDefaultImports`](#allowSyntheticDefaultImports).

packages/tsconfig-reference/copy/pt/options/moduleResolution.md

@@ -0,0 +1,9 @@
+---
+display: "Resolução de Módulos"
+oneline: "Permite estratégias de resolução de módulos TypeScript 1.6"
+---
+
+Especifica a estratégia de resolução de módulos: `'node'` (Node.js) ou `classic` (utilizada no TypeScript antes da versão 1.6).
+Você provavelmente não vai precisar utilizar `classic` em código atual.
+
+Há uma página de referência em [Resolução de Módulos](/docs/handbook/module-resolution.html)

packages/tsconfig-reference/copy/pt/options/paths.md

@@ -0,0 +1,39 @@
+---
+display: "Caminhos"
+oneline: "Um conjunto de locais para buscar importações"
+---
+
+Uma série de entradas que remapeiam as importações para locais de pesquisa relativos à `baseUrl`, há uma cobertura mais abrangente de `paths` no [handbook](/docs/handbook/module-resolution.html#path-mapping).
+
+`paths` permite que você declare como o TypeScript deve resolver importações nos seus `requires` e `imports`.
+
+```json
+{
+  "compilerOptions": {
+    "baseUrl": ".", // isto deve ser especificado se "paths" está especificado.
+    "paths": {
+      "jquery": ["node_modules/jquery/dist/jquery"] // este mapeamento é relativo à "baseUrl"
+    }
+  }
+}
+```
+
+Isto permitiria que você escreva `import "jquery"`, e obtenha toda a digitação correta localmente.
+
+```json
+{
+  "compilerOptions": {
+    "baseUrl": "src",
+    "paths": {
+        "app/*": ["app/*"],
+        "config/*": ["app/_config/*"],
+        "environment/*": ["environments/*"],
+        "shared/*": ["app/_shared/*"],
+        "helpers/*": ["helpers/*"],
+        "tests/*": ["tests/*"]
+    },
+}
+```
+
+Neste caso, você pode infomar o resolvedor de arquivos do TypeScript para dar suporte à vários prefixos personalizados para encontrar código.
+Este padrão pode ser usado para evitar caminhos relativos longos no seu código base.

packages/tsconfig-reference/copy/pt/options/preserveSymlinks.md

@@ -0,0 +1,10 @@
+---
+display: "Preservar Symlinks"
+oneline: "Não resolva caminhos de links simbólicos"
+---
+
+Isto é para refletir a mesma flag do Node.js; que não resolve o caminho real de links simbólicos.
+
+Esta flag também exibe o comportamento oposto ao da opção `resolve.symlinks` do Webpack (ou seja, definir `preserveSymlinks` do TypeScript para true é o mesmo que definir `resolve.symlinks` do Webpack para false, e vice-versa).
+
+Com isto habilitado, as referências para módulos e pacotes (p. ex. diretivas `import` e `/// <reference type="..." />`) são todas resolvidas em relação ao local do arquivo symlink, em vez de relativas ao caminho que o symlink resolve.

packages/tsconfig-reference/copy/pt/options/typeRoots.md

@@ -0,0 +1,21 @@
+---
+display: "Raizes de Tipo"
+oneline: "Locais onde o TypeScript deve buscar por definições de tipo"
+---
+
+Por padrão todos pacotes "`@types`" _visíveis_ são incluídos na sua compilação.
+Pacotes em `node_modules/@types` de qualquer diretório adjacente são considerados _visíveis_.
+Por exemplo, isso significa pacotes dentro de `./node_modules/@types/`, `../node_modules/@types/`, `../../node_modules/@types/`, e assim por diante.
+
+Se `typeRoots` está especificado, _somente_ pacotes dentro de `typeRoots` serão incluídos. Por exemplo:
+
+```json
+{
+  "compilerOptions": {
+    "typeRoots": ["./typings", "./vendor/types"]
+  }
+}
+```
+
+Este arquivo de configuração vai incluir _todos_ os pacotes definidos em `./typings` e `./vendor/types` , e nenhum pacote de `./node_modules/@types`.
+Todo os caminhos são relativos ao arquivo `tsconfig.json`.

packages/tsconfig-reference/copy/pt/options/types.md

@@ -0,0 +1,40 @@
+---
+display: "Tipos"
+oneline: "Utilizada para criar uma lista de tipos permitidos, a serem incluídos na compilação"
+---
+
+Por padrão todos pacotes "`@types`" _visíveis_ são incluídos na sua compilação.
+Pacotes em `node_modules/@types` de qualquer diretório adjacente são considerados _visíveis_.
+Por exemplo, isso significa pacotes dentro de `./node_modules/@types/`, `../node_modules/@types/`, `../../node_modules/@types/`, e assim por diante.
+
+Se `types` está especificado, somente pacotes listados serão incluídos no escopo global. Por exemplo:
+
+```json
+{
+  "compilerOptions": {
+    "types": ["node", "jest", "express"]
+  }
+}
+```
+
+Este arquivo `tsconfig.json` _somente_ irá incluir `./node_modules/@types/node`, `./node_modules/@types/jest` e `./node_modules/@types/express`.
+Outros pacotes dentro de `node_modules/@types/*` não serão incluídos.
+
+### O que isto reflete?
+
+Esta opção não altera como `@types/*` são incluídos no código da sua aplicação, por exemplo se você tivesse o `compilerOptions` acima, com o seguinte código:
+
+```ts
+import * as moment from "moment";
+
+moment().format("MMMM Do YYYY, h:mm:ss a");
+```
+
+O import `moment` estaria completamente tipado.
+
+Quando você tem esta opção definida, ao não incluir um módulo no vetor de `types`, ela:
+
+- Não vai adicionar globais ao seu projeto (p. ex. `process` no node, ou `expect` no Jest)
+- Não vai fazer com que exports apareçam como recomendações de auto-import
+
+Esta característica difere de [`typeRoots`](#typeRoots) , pois serve para especificar somente os tipos exatos a serem incluídos, enquanto [`typeRoots`](#typeRoots) permite que você defina diretórios específicos.