feat: add 'back/front end' in curriculum (#42596)

* chore: rename APIs and Microservices to include "Backend" (#42515)

* fix typo

* fix typo

* undo change

* Corrected grammar mistake

Corrected a grammar mistake by removing a comma.

* change APIs and Microservices cert title

* update title

* Change APIs and Microservices certi title

* Update translations.json

* update title

* feat(curriculum): rename apis and microservices cert

* rename folder structure

* rename certificate

* rename learn Markdown

* apis-and-microservices -> back-end-development-and-apis

* update backend meta

* update i18n langs and cypress test

Co-authored-by: Shaun Hamilton <shauhami020@gmail.com>

* fix: add development to front-end libraries (#42512)

* fix: added-the-word-Development-to-front-end-libraries

* fix/added-the-word-Development-to-front-end-libraries

* fix/added-word-development-to-front-end-libraries-in-other-related-files

* fix/added-the-word-Development-to-front-end-and-all-related-files

* fix/removed-typos-from-last-commit-in-index.md

* fix/reverted-changes-that-i-made-to-dependecies

* fix/removed xvfg

* fix/reverted changes that i made to package.json

* remove unwanted changes

* front-end-development-libraries changes

* rename backend certSlug and README

* update i18n folder names and keys

* test: add legacy path redirect tests

This uses serve.json from the client-config repo, since we currently use
that in production

* fix: create public dir before moving serve.json

* fix: add missing script

* refactor: collect redirect tests

* test: convert to cy.location for stricter tests

* rename certificate folder to 00-certificates

* change crowdin config to recognise new certificates location

* allow translations to be used

Co-authored-by: Nicholas Carrigan (he/him) <nhcarrigan@gmail.com>

* add forwards slashes to path redirects

* fix cypress path tests again

* plese cypress

* fix: test different challenge

Okay so I literally have no idea why this one particular challenge
fails in Cypress Firefox ONLY. Tom and I paired and spun a full build
instance and confirmed in Firefox the page loads and redirects as
expected. Changing to another bootstrap challenge passes Cypress firefox
locally. Absolutely boggled by this.

AAAAAAAAAAAAAAA

* fix: separate the test

Okay apparently the test does not work unless we separate it into
a different `it` statement.

>:( >:( >:( >:(

Co-authored-by: Sujal Gupta <55016909+heysujal@users.noreply.github.com>
Co-authored-by: Noor Fakhry <65724923+NoorFakhry@users.noreply.github.com>
Co-authored-by: Oliver Eyton-Williams <ojeytonwilliams@gmail.com>
Co-authored-by: Nicholas Carrigan (he/him) <nhcarrigan@gmail.com>
This commit is contained in:
Shaun Hamilton
2021-08-14 03:57:13 +01:00
committed by GitHub
parent 4df2a0c542
commit c2a11ad00d
1215 changed files with 790 additions and 449 deletions

View File

@ -0,0 +1,52 @@
---
id: 587d7fb3367417b2b2512bfc
title: Adicionar uma descrição ao package.json
challengeType: 2
forumTopicId: 301522
dashedName: add-a-description-to-your-package-json
---
# --description--
A próxima parte de um bom arquivo package.json é o campo `description`. É aqui que você deve colocar uma descrição curta, mas informativa, do projeto.
Se você planeja publicar um pacote no npm, esta é a string que deve vender a ideia ao usuário para que ele decida se deseja instalar o pacote ou não. No entanto, esse não é o único caso de uso para a descrição. Ela é uma ótima maneira de resumir o que um projeto faz. Também é importante, em qualquer projeto do Node.js, ajudar outros desenvolvedores, futuros mantenedores ou, até mesmo, seu futuro eu a entender rapidamente o projeto.
Independentemente do que você planeja para seu projeto, uma descrição é definitivamente recomendada. Exemplo:
```json
"description": "A project that does something awesome",
```
# --instructions--
Adicione uma `description` ao arquivo package.json do projeto.
**Observação:** lembre-se de usar aspas duplas para nomes de campo (") e vírgulas (,) para separar os campos.
# --hints--
O package.json deve ter uma chave "description" válida
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/package.json').then(
(data) => {
var packJson = JSON.parse(data);
assert(packJson.description, '"description" is missing');
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,48 @@
---
id: 587d7fb4367417b2b2512bfe
title: Adicionar uma licença ao package.json
challengeType: 2
forumTopicId: 301523
dashedName: add-a-license-to-your-package-json
---
# --description--
O campo `license` é onde você informa aos usuários o que eles têm permissão para fazer com o seu projeto.
Algumas licenças comuns para projetos de código aberto incluem a MIT e a BSD. Informações de licença não são necessárias. As leis de direitos autorais na maioria dos países lhe darão a propriedade do que você criou por padrão. No entanto, é sempre uma boa prática indicar explicitamente o que os usuários podem e não podem fazer. Aqui está um exemplo do campo license:
```json
"license": "MIT",
```
# --instructions--
Preencha o campo `license` no arquivo package.json do seu projeto conforme achar adequado.
# --hints--
O package.json deve ter uma chave "license" válida
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/package.json').then(
(data) => {
var packJson = JSON.parse(data);
assert(packJson.license, '"license" is missing');
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,46 @@
---
id: 587d7fb4367417b2b2512bff
title: Adicionar uma versão ao package.json
challengeType: 2
forumTopicId: 301525
dashedName: add-a-version-to-your-package-json
---
# --description--
Um dos campos obrigatórios do seu arquivo package.json é o `version`. Este campo descreve a versão atual do seu projeto. Exemplo:
```json
"version": "1.2.0",
```
# --instructions--
Adicione uma `version` ao arquivo package.json do projeto.
# --hints--
O package.json deve ter uma chave "version" válida
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/package.json').then(
(data) => {
var packJson = JSON.parse(data);
assert(packJson.version, '"version" is missing');
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,84 @@
---
id: 587d7fb4367417b2b2512bfd
title: Adicionar palavras-chave ao seu package.json
challengeType: 2
forumTopicId: 301526
dashedName: add-keywords-to-your-package-json
---
# --description--
O campo `keywords` é onde você pode descrever seu projeto usando palavras-chave relacionadas. Exemplo:
```json
"keywords": [ "descriptive", "related", "words" ],
```
Como você pode ver, este campo está estruturado como um array de frases cercadas por aspas duplas.
# --instructions--
Adicione uma array de strings adequadas para o campo `keywords` no arquivo package.json do seu projeto.
Uma das palavras-chave deve ser "freecodecamp".
# --hints--
package.json deve ter uma chave "keywords" válida
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/package.json').then(
(data) => {
var packJson = JSON.parse(data);
assert(packJson.keywords, '"keywords" is missing');
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
O campo "keywords" deve ser um array
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/package.json').then(
(data) => {
var packJson = JSON.parse(data);
assert.isArray(packJson.keywords, '"keywords" is not an array');
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
O campo "keywords" devem incluir "freecodecamp"
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/package.json').then(
(data) => {
var packJson = JSON.parse(data);
assert.include(
packJson.keywords,
'freecodecamp',
'"keywords" does not include "freecodecamp"'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,77 @@
---
id: 587d7fb4367417b2b2512c00
title: Expandir seu projeto com pacotes externos do npm
challengeType: 2
forumTopicId: 301527
dashedName: expand-your-project-with-external-packages-from-npm
---
# --description--
Uma das maiores razões para usar um gerenciador de pacotes é a sua poderosa gestão de dependências. Em vez de ter que garantir manualmente que tem todas as dependências sempre que você configurar um projeto em um novo computador, o npm instala tudo automaticamente para você. Mas como o npm pode saber exatamente de que seu projeto precisa? Conheça a seção `dependencies` do seu arquivo package.json.
Nesta seção, pacotes de que seu projeto necessita são armazenados usando o seguinte formato:
```json
"dependencies": {
"package-name": "version",
"express": "4.14.0"
}
```
# --instructions--
Adicione a versão "2.14.0" do pacote "moment" ao campo `dependencies` do seu arquivo package.json.
**Observação:** o moment é uma biblioteca útil para trabalhar com horas e datas.
# --hints--
"dependencies" deve incluir o "moment"
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/package.json').then(
(data) => {
var packJson = JSON.parse(data);
assert.property(
packJson.dependencies,
'moment',
'"dependencies" does not include "moment"'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
A versão do "moment" deve ser a "2.14.0"
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/package.json').then(
(data) => {
var packJson = JSON.parse(data);
assert.match(
packJson.dependencies.moment,
/^[\^\~]?2\.14\.0/,
'Wrong version of "moment" installed. It should be 2.14.0'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,60 @@
---
id: 587d7fb3367417b2b2512bfb
title: 'Utilizar o package.json, o centro de qualquer projeto do Node.js ou pacote npm'
challengeType: 2
forumTopicId: 301528
dashedName: how-to-use-package-json-the-core-of-any-node-js-project-or-npm-package
---
# --description--
Trabalhar nesses desafios vai fazer com que você escreva seu código usando um dos seguintes métodos:
- Clone [este repositório do GitHub](https://github.com/freeCodeCamp/boilerplate-npm/) e complete esses desafios localmente.
- Use [nosso projeto inicial do Replit](https://replit.com/github/freeCodeCamp/boilerplate-npm) para completar esses desafios.
- Use um construtor de site de sua escolha para completar o projeto. Certifique-se de incorporar todos os arquivos do nosso repositório no GitHub.
Quando terminar, certifique-se de que uma demonstração funcional do seu projeto está hospedada em algum lugar público. Em seguida, envie o URL para ela no campo `Solution Link`. Como opção, envie também um link para o código-fonte do projeto no campo `GitHub Link`.
O arquivo `package.json` é o centro de qualquer projeto do Node.js ou pacote do npm. Ele armazena informações sobre seu projeto, de modo semelhante ao que a seção &lt;head> de um documento HTML usa para descrever o conteúdo de uma página da web. Ele consiste em um único objeto JSON, onde as informações são armazenadas em pares de chave-valor. Existem apenas dois campos obrigatórios: "name" e "version". Porém, é uma boa prática fornecer informações adicionais sobre o seu projeto que possam ser úteis para futuros usuários ou mantenedores.
Se você olhar a árvore de arquivos do projeto, você encontrará o arquivo package.json no nível superior da árvore. Este é o arquivo que você vai melhorar nos próximos desafios.
Uma das informações mais comuns neste arquivo é o campo `author`. Especifica quem criou o projeto e pode consistir em uma string ou um objeto com detalhes de contato ou outros. Um objeto é recomendado para projetos maiores, mas uma string simples como o exemplo a seguir já servirá para este projeto.
```json
"author": "Jane Doe",
```
# --instructions--
Adicione seu nome como o `author` do projeto no arquivo package.json.
**Observação:** lembre-se de que você está escrevendo JSON. Então, todos os nomes de campos devem usar aspas duplas (") e ser separados por uma vírgula (,).
# --hints--
O package.json deve ter uma chave "author" válida
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/package.json').then(
(data) => {
var packJson = JSON.parse(data);
assert(packJson.author, '"author" is missing');
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,73 @@
---
id: 587d7fb5367417b2b2512c01
title: Gerenciar dependências do npm entendendo o versionamento semântico
challengeType: 2
forumTopicId: 301529
dashedName: manage-npm-dependencies-by-understanding-semantic-versioning
---
# --description--
As `Versions` (versões) dos pacotes do npm na seção de dependências do seu arquivo package.json seguem o que chamamos de Semantic Versioning (SemVer), um padrão do setor para versionamento de software, com o objetivo de facilitar o gerenciamento de dependências. Bibliotecas, frameworks ou outras ferramentas publicadas no npm devem usar o SemVer para comunicar claramente que tipo de mudanças os projetos podem esperar caso eles atualizem.
Conhecer o SemVer pode ser útil quando você desenvolve um software que usa dependências externas (algo que você faz quase sempre). Um dia, seu entendimento desses números vai evitar que você introduza acidentalmente alterações que causem problemas em seu projeto, sem compreender por que as coisas que funcionaram ontem, de repente, não funcionam hoje. É assim que o Versionamento Semântico funciona de acordo com o site oficial:
```json
"package": "MAJOR.MINOR.PATCH"
```
A versão MAJOR (principal) deve incrementar quando você fizer alterações incompatíveis na API. A versão MINOR (secundária) deve incrementar quando adicionar funcionalidades retrocompatíveis. A versão PATCH deve incrementar quando você fizer consertos de bugs retrocompatíveis. Isso significa que PATCHes são correções de bugs e MINORs adicionam novas funcionalidades, mas nenhum deles quebra o que funcionava antes. Por fim, as MAJORs adicionam alterações que não funcionarão com versões anteriores.
# --instructions--
Na seção de dependências do seu arquivo package.json, altere a `version` do moment para que corresponda à versão MAJOR 2, à versão MINOR 10 e à versão 2 de PATCH
# --hints--
As "dependencies" devem incluir o "moment"
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/package.json').then(
(data) => {
var packJson = JSON.parse(data);
assert.property(
packJson.dependencies,
'moment',
'"dependencies" does not include "moment"'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
A versão do "moment" deve ser a "2.14.0"
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/package.json').then(
(data) => {
var packJson = JSON.parse(data);
assert.equal(
packJson.dependencies.moment,
'2.10.2',
'Wrong version of "moment". It should be 2.10.2'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,52 @@
---
id: 587d7fb5367417b2b2512c04
title: Remover um pacote de suas dependências
challengeType: 2
forumTopicId: 301530
dashedName: remove-a-package-from-your-dependencies
---
# --description--
Você agora já testou algumas maneiras de gerenciar as dependências do seu projeto usando a seção de dependências do package.json. Você também incluiu pacotes externos, adicionando-os ao arquivo e até dizendo ao npm quais tipos de versões você quer, usando caracteres especiais como o til ou o circunflexo.
Mas e se você quisesse remover um pacote externo do qual você não precisa mais? Você já deve ter adivinhado: apenas remova o par chave-valor correspondente a esse pacote das dependências.
Este mesmo método também se aplica à remoção de outros campos no seu package.json
# --instructions--
Remover o pacote do moment de suas dependências.
**Observação:** certifique-se de que você tem a quantidade certa de vírgulas depois de removê-lo.
# --hints--
As "dependencies" não devem incluir o "moment"
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/package.json').then(
(data) => {
var packJson = JSON.parse(data);
assert.notProperty(
packJson.dependencies,
'moment',
'"dependencies" still includes "moment"'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,75 @@
---
id: 587d7fb5367417b2b2512c03
title: Usar o circunflexo para usar a última versão secundária de uma dependência
challengeType: 2
forumTopicId: 301531
dashedName: use-the-caret-character-to-use-the-latest-minor-version-of-a-dependency
---
# --description--
Da mesma forma que o til, que aprendemos no último desafio e que permite que o npm instale o último PATCH de uma dependência, o circunflexo (`^`) permite que o npm instale atualizações futuras também. A diferença é que o circunflexo permitirá tanto atualizações MINOR quanto PATCHes.
Sua versão atual neste momento deve ser "~2.10.2", o que permite que o npm instale a versão 2.10.x mais recente. Se você usasse o circunflexo (^) como um prefixo de versão, o npm teria permissão para atualizar para qualquer versão 2.x.x.
```json
"package": "^1.3.8"
```
Isso permitiria atualizações para qualquer versão 1.x.x do pacote.
# --instructions--
Use o circunflexo (`^`) para prefixar a versão do momento em suas dependências e permitir que o npm atualize para qualquer versão MINOR.
**Observação:** os números da versão em si não devem ser alterados.
# --hints--
"dependencies" deve incluir o "moment"
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/package.json').then(
(data) => {
var packJson = JSON.parse(data);
assert.property(
packJson.dependencies,
'moment',
'"dependencies" does not include "moment"'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
A versão do "moment" deve corresponder a "^2.x.x"
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/package.json').then(
(data) => {
var packJson = JSON.parse(data);
assert.match(
packJson.dependencies.moment,
/^\^2\./,
'Wrong version of "moment". It should be ^2.10.2'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```

View File

@ -0,0 +1,75 @@
---
id: 587d7fb5367417b2b2512c02
title: Usar o til para usar sempre a última versão de patch de uma dependência
challengeType: 2
forumTopicId: 301532
dashedName: use-the-tilde-character-to-always-use-the-latest-patch-version-of-a-dependency
---
# --description--
No último desafio, você disse ao npm para incluir apenas uma versão específica de um pacote. Essa é uma maneira útil de congelar suas dependências, caso você precise garantir que diferentes partes do seu projeto permaneçam compatíveis entre si. Mas, na maioria dos casos de uso, você não quer perder as correções de erros, já que elas geralmente incluem correções de segurança importantes e (esperamos que) não quebrem nada ao fazer isso.
Para permitir que uma dependência do npm atualize para a última versão de PATCH, você pode prefixar a versão da dependência com o caractere de til (`~`). Aqui está um exemplo de como permitir atualizações para qualquer versão 1.3.x.
```json
"package": "~1.3.8"
```
# --instructions--
No arquivo package.json, sua regra atual de como o npm pode atualizar o moment é usar uma versão específica (2.10.2). Mas agora, você deseja permitir a última versão de 2.10.x.
Use o caractere de til (`~`) para prefixar a versão do momento em suas dependências e permitir que o npm atualize para qualquer versão de PATCH.
**Observação:** os números da versão em si não devem ser alterados.
# --hints--
"dependencies" deve incluir o "moment"
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/package.json').then(
(data) => {
var packJson = JSON.parse(data);
assert.property(
packJson.dependencies,
'moment',
'"dependencies" does not include "moment"'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
A versão do "moment" deve corresponder a "~2.10.2"
```js
(getUserInput) =>
$.get(getUserInput('url') + '/_api/package.json').then(
(data) => {
var packJson = JSON.parse(data);
assert.match(
packJson.dependencies.moment,
/^\~2\.10\.2/,
'Wrong version of "moment". It should be ~2.10.2'
);
},
(xhr) => {
throw new Error(xhr.responseText);
}
);
```
# --solutions--
```js
/**
Backend challenges don't need solutions,
because they would need to be tested against a full working project.
Please check our contributing guidelines to learn more.
*/
```