- A uma certa diferença do projeto do professor para esse, basicamente libs, no meu por exemplo estou usando o Vite, para não ter que baixar o create-react-app e o webpack...
- Irei usar o Vite e talvez o Tailwind.css
-
Na aula 1 introdução foi ensinando a criar alias para o Git para subir o projeto, facilitando os commits.
-
Caso o git que você instalou colocou o editor padrão vim ou VI e quer usar o vscode para mudar basta colocar isso em algum terminal(cmd, vscode...):
git config --global core.editor code --wait, com isso ele vai abrir o vscode para editar o commit. -
git config --global --edit: Basta inserir isso em algum terminal. Com isso, ele abre o arquivo de configuração do git .gitconfig, onde você pode adicionar alias para comandos do git. Lembrando que a flag--globalé para alterar do usuário, tem somente do projeto--locale do sistema--systemtodos os projetos e usuários da maquina. Ex do gitconfig em outras maquinas e arquivo de exemplo do .gitconfig na pasta note. -
O professor criou uma pasta
git-aliassomente para demonstrar os commits usando esses atalhos que ele mesmo criou dentro do arquivo .gitconfig que ele abriu com o comandogit config --global --edit.:Alias(apelido): Atalhos do git
[push] followTags = true [alias] c = !git add --all && git commit -m s = !git status -s l = !git log --pretty=format:'%C(blue)%h%C(red)%d %C(white)%s - %C(cyan)%cn, %C(green)%cr' amend = !git add --all && git commit --amend --no-edit count = !git shortlog -s --grep
-
Na aula 2 configurou as dependências e padronizou os commits:
-
Conventionalcommits: Basicamente ele padroniza a maneira de commitar os projetos.
-
Podemos usar o
npm i git-commit-msg-linter(parece com um pre-commit(tipo o husky: Integrate-commitlint-to-your-repository nesse caso aqui você consegue usar ogithub desktop)) para facilitar a padronização dos commits. Basicamente ele impede de enviar algum commit sem estar no padrão. Obs: Ao usar o github desktop ele não funciona, da um erro de wsl, somente via CLI que está funcionando: Error-git-commit-msg-linter -
Padrão dos commits, ex:
feat: add login button.
-
Se não fizer isso, dará esse erro:
**\*\***\***\*\*** Mensagem de commit inválida **\*\***\*\***\*\*** mensagem de commit: sdfsdf Comprimento inválido: Comprimento 6. Mensagem de commit não pode ser maior que 100 caracteres ou menor que 10 formato correto: <type>(scope): <subject> exemplo: docs: atualiza o README com link para a nova documentação type: feat Adição de funcionalidade. fix Correção de defeito. docs Mudança em documentação. style Mudança de formatação ou estilo, que não afeta a execução do código (espaço, tabulação, etc). refactor Mudança na organização do código, que não afeta o comportamento existente. test Adição ou mudança de um teste. chore Adição ou mudança em script de build, que não afeta o código de produção. perf Mudança de código para melhoria de desempenho. ci Mudança de configuração de integração contínua. build Mudança em arquivos de build ou em dependências externas. temp Commit temporário, que não deve ser incluído no CHANGELOG. scope: Opcional, pode ser qualquer coisa que especifique o escopo da mudança. Exemplos: subpacote, workspace, módulo, componente, página. subject: Breve resumo da mudança, escrito no tempo verbal presente. Começa com letra minúscula e não há ponto final.
-
Essa é a forma que eu crio meus commits (conventional commits) - Rocketseat
-
GIT: Mini Curso para Você Sair do Zero! (Aprenda em 45 Minutos)
-
Boas práticas com GIT (importante se você trabalha com time)
-
Como deve ser os commits:
-
O commit tem que ser o mais simples possível.
-
A mensagem commit você tem que ler da seguinte forma: "Se aplicado, esse commit vai..." e ai mensagem de commit tem que continuar a frase, por isso a mensagem de commit nunca é no passado.
- Errado: "added support to spanish on uploads"
- Certo: "add support to spanish on uploads"
-
Na mensagem de commit você não coloca explicação da motivação de estar criando esse commit, a motivação(por que você esta fazendo esse commit) e o que esse commit faz(explicação) vem na descrição pode ser feito em Ingles ou Portuguese.
-
Depois so abrir uma pr ou dar push direto pra raiz principal
-
-
sequencia de commit CLI sem o uso de alias do professor:
# Todos os arquivos Git add . # git commit ou git commit -a: Se você tiver no windows ele vai abrir no editor de texto padrão que você definiu na instalação do git(no meu caso vs code) o arquivo COMMIT_EDITMSG.git, ai você coloca a mensagem de commit, salva e feche o arquivo, apos colocar o que deseja e fechar o arquivo, ele ira fazer o [commit automaticamente](https://stackoverflow.com/questions/30149132/multiline-git-commit-message-in-vscode ou https://github.com/stkb/Rewrap/wiki/Settings-VSCode#wrapping-to-rulers).(No video do diego rockeseat ele usa o vim no mac) Git commit -m "feat: add login button" # git push origin main: empurra para o github ou cria uma pr(pull request) Git push origin main
-
Usando os alias:
Git c "feat: add login button" Git push origin main -
ESLint. O ESLint implementa o processo de Linting, que é responsável por aplicar regras a uma base de código e destacar padrões ou códigos problemáticos, sem a necessidade do código ser executado
-
Error:
@typescript-eslint/eslint-plugin@"^6.4.0" from eslint-config-standard-with-typescript@43.0.1: Somente na sua versãoeslint-config-standard-with-typescript@11funciona com o Eslint@typescript-eslint/parser@7.1.1e@typescript-eslint/eslint-plugin@7.1.1:npm i eslint-config-standard-with-typescript -D npm ERR! code ERESOLVE npm ERR! ERESOLVE unable to resolve dependency tree npm ERR! npm ERR! While resolving: reactjs-hooks-tdd-clean-architecture-solid-patterns2@0.0.0 npm ERR! Found: @typescript-eslint/eslint-plugin@7.2.0 npm ERR! node_modules/@typescript-eslint/eslint-plugin npm ERR! dev @typescript-eslint/eslint-plugin@"^7.1.1" from the root project npm ERR! npm ERR! Could not resolve dependency: npm ERR! peer @typescript-eslint/eslint-plugin@"^6.4.0" from eslint-config-standard-with-typescript@43.0.1 npm ERR! node_modules/eslint-config-standard-with-typescript npm ERR! dev eslint-config-standard-with-typescript@"\*" from the root project npm ERR! npm ERR! Fix the upstream dependency conflict, or retry npm ERR! this command with --force or --legacy-peer-deps npm ERR! to accept an incorrect (and potentially broken) dependency resolution. npm ERR! npm ERR! npm ERR! For a full report see: npm ERR! C:\Users\Pedro\AppData\Local\npm-cache_logs\2024-03-14T14_34_10_878Z-eresolve-report.txt npm ERR! A complete log of this run can be found in: C:\Users\Pedro\AppData\Local\npm-cache_logs\2024-03-14T14_34_10_878Z-debug-0.log npm ERR! ERESOLVE unable to resolve dependency tree npm ERR! npm ERR! While resolving: reactjs-hooks-tdd-clean-architecture-solid-patterns2@0.0.0 npm ERR! Found: @typescript-eslint/parser@7.2.0 npm ERR! node_modules/@typescript-eslint/parser npm ERR! dev @typescript-eslint/parser@"^7.1.1" from the root project npm ERR! npm ERR! Could not resolve dependency: ...
-
Se quiser usar a versão mais atual do standard você tera que que usar a versão 6.4.0 do @typescript-eslint/eslint-plugin e @typescript-eslint/parser, tanto um como o outro tem que estar na mesma versão(de acordo com o momento atual) https://www.npmjs.com/package/eslint-config-standard-with-typescript.
-
Mas o problema que o 11 não suporta v3(typescript-eslint/typescript-eslint#2077) do @typescript-eslint/eslint-plugin, @typescript-eslint/parser... dando o erro: error Definition for rule '@typescript-eslint/camelcase' was not found @typescript-eslint/camelcase
-
Com isso, configuramos no arquivo .eslintrc.json/ts/js/cjs:"@typescript-eslint/camelcase": "off" para desabilitar o erro.
-
Forma antiga V4 Migrate from v4
-
npm i lint-staged husky -D: Impede que façamos commits defeituosos em relação codigo -
o arquivo junto com a lib lint-staged .lintstagedrc.json ela pega todos os arquivos que esteja prontos para entrar no proximo commit, ou seja, arquivos modificados, em cima desses arquivos queremos aplicar alguns scripts antes de fazer o commit, ex: eslint, prettier, testes, etc...
{ "\*.{js,jsx,ts,tsx}": [ "eslint --fix", "prettier --write", "git add" ] }{ "*/**/*.{ts,tsx}": [ "eslint --fix", "eslint" ] } -
Basicamente o eslint tenta corrigir os arquivos antes de enviar .huskyrc.json
{ "hooks": { "pre-commit": "lint-staged" } } -
E agora vem o husky, precisamos colocar isso junto com o husky
-
Nele vamos definir hooks para o git, como o pre-commit, basicamente passamos um script para rodar no pre-commit, o lint-staged, toda vez que formos fazer um commit, o husky dispara esse pre-commit, antes do pre-commit rodar, ele executa o comando lint-staged, que nada mais é que o arquivo .lintstagedrc.json
-
-
Nova forma V9 do HuskyIntroduction e Migrate from v4
#Instala npm i husky -D #Init npx husky init #Script criado no package.json: { "scripts": { "prepare": "husky" }, } #Apos isso, ele cria uma pasta .husky e cria um script de setup(Prepare), basta você dar uma vez esse comando. Lembrando que o .git tem que estar na raiz do projeto, se não tiver ele não vai funcionar. npm run prepare #Apos dar esse comendo, ele cria um monte de arquivo na pasta, mas o mais importe o que esta na raiz dela, o .husky/pre-commit, que é o script que ele vai rodar antes de fazer o commit: Agora é so colocar o que ele deve executar antes de fazer o commit, no caso o lint-staged ou um comando direto do package.json, ex: npm lint. Pode colocar o prefixo run antes ou nem coloque: #Ex: nesse caso ele rodaria os testes antes de enviar npm test #Ex: nesse caso ele rodaria o lint-staged antes de enviar. Nesse caso você cria um arquivo .lintstagedrc.json na raiz do projeto, e coloca os comandos. Se não você coloca diretamente no package.json npx lint-staged # No package.json: "lint-staged": { "*/**/*.{ts,tsx}": [ "eslint --fix", "eslint" ] } # No arquivo separado .lintstagedrc.json: { "*/**/*.{ts,tsx}": [ "eslint --fix", "eslint" ] } # Caso você queira pode colocar o comando direto no pre-commit do husky: npm run lint ou npm lint npm run lint:fix ou npm lint:fix npm run test ou npm test
-
Tenha em mente que a pasta .git esteja a onde você quer usar o husky, pois ele cria uma pasta .git/hooks, que é onde ele vai colocar os hooks, se não tiver a pasta .git, ele não vai funcionar. Por exemplo se no repositório você criou umas subs pastas para fazer front e a api, dentro do front e api não vai possui a pasta .git, porque o .git fica na raiz de tudo, ou seja, na pasta do projeto do repositório, antes de entrar nas subs pastas que você criou. Para ver ela basta abrir o projeto no windows explorer e habilitar a opção de mostrar pastas ocultas. Se não tiver ele vai dar esse erro quando tentar dar um npm run prepare:
npm run prepare > reactjs-hooks-tdd-clean-architecture-solid-patterns2@0.0.0 prepare > husky .git can't be found
-
Links de ajuda para instalar o Husky(Algumas coisas estão desatualizadas, mas ajudaram a tomar um norte):
-
Por fim o Husky agora funciona no projeto, mas o eslint que o professor configurou esta todo desatualizando:
module.exports = { root: true, env: { browser: true, es2020: true }, // Extends: Realiza o extend da biblioteca ESLint, que implanta a análise do style guidesJS Standard Style, definido a estrutura que deve ser utilizada como default; extends: [ // Inseridos por mim // Estende o style guide do eslint com as regras do standard 'standard-with-typescript', // Ja veio com vite 'eslint:recommended', // O plugin: --> Nada mais é que a lib @typescript-eslint/eslint-plugin 'plugin:@typescript-eslint/recommended', 'plugin:react-hooks/recommended', ], ignorePatterns: ['dist', '.eslintrc.cjs', '*.config.*'], // Inserido por mim parserOptions: { // Define o parser que será utilizado para analisar o código parser: '@typescript-eslint/parser', // Define o arquivo de configuração do typescript para ser usado pelo ESLint project: `${__dirname}/tsconfig.json` }, // Do vite // parser: '@typescript-eslint/parser', plugins: ['react-refresh'], rules: { 'react-refresh/only-export-components': [ 'warn', { allowConstantExport: true }, ], // Inserido por mim // desabilita a config do eslint onde ele dita que so pode usar ou interface ou type "@typescript-eslint/consistent-type-definitions": "off", // ele não deixa fazer comparação que não seja booleana "@typescript-eslint/strict-boolean-expressions": "off", // error Definition for rule '@typescript-eslint/camelcase' was not found @typescript-eslint/camelcase "@typescript-eslint/camelcase": "off", }, } -
Vou usar um pacote meu para configurar o eslint:
npm i @pedrohvfernandes/eslint-confige dar uninstall:npm uninstall eslint-config-standard-with-typescript eslint-plugin-import eslint-plugin-node eslint-plugin-promise eslint-plugin-react eslint-plugin-react-hooks eslint-plugin-react-refresh eslint-plugin-standard @typescript-eslint/eslint-plugin @typescript-eslint/parser
-
Por fim pro arquivo do eslint eu mudou o tipo do arquivo dele para .json e estendo minha config do React
-
-
E por fim jest que tive que colocar .cjs, em ts estava dando esse erro ao tentar rodar os testes:
Error: Jest: Failed to parse the TypeScript config file C:\Users\Pedro\OneDrive\Documentos\GitHub\tdd-clean-architecture-solid\reactjs-hooks-tdd-clean-architecture-solid-patterns\jest.config.ts Error: Jest: 'ts-node' is required for the TypeScript configuration files. Make sure it is installed Error: Cannot find package 'ts-node' imported from C:\Users\Pedro\OneDrive\Documentos\GitHub\tdd-clean-architecture-solid\reactjs-hooks-tdd-clean-architecture-solid-patterns\node_modules\jest-config\build\readConfigFileAndSetRootDir.js ...
-
Em js
Error: Jest: Failed to parse the TypeScript config file C:\Users\Pedro\OneDrive\Documentos\GitHub\tdd-clean-architecture-solid\reactjs-hooks-tdd-clean-architecture-solid-patterns\jest.config.ts Error: Jest: 'ts-node' is required for the TypeScript configuration files. Make sure it is installed Error: Cannot find package 'ts-node' imported from C:\Users\Pedro\OneDrive\Documentos\GitHub\tdd-clean-architecture-solid\reactjs-hooks-tdd-clean-architecture-solid-patterns\node_modules\jest-config\build\readConfigFileAndSetRootDir.js at readConfigFileAndSetRootDir (C:\Users\Pedro\OneDrive\Documentos\GitHub\tdd-clean-architecture-solid\reactjs-hooks-tdd-clean-architecture-solid-patterns\node_modules\jest-config\build\readConfigFileAndSetRootDir.js:116:13) at async readInitialOptions (C:\Users\Pedro\OneDrive\Documentos\GitHub\tdd-clean-architecture-solid\reactjs-hooks-tdd-clean-architecture-solid-patterns\node_modules\jest-config\build\index.js:403:13) ...
-
Programação
-
Scripts de teste:
# Teste base # --passWithNoTests: Passa se não tiver testes, caso mexemos em um arquivo que não tem teste, ele vai passar "test": "jest --passWithNoTests", # Todos esses testes vão herdar do base # Com -- ele herda o que tem no outro e roda o que tem em seguida no caso o --watch "test:watch": "npm test -- --watch", # Ele procura dentro de arquivos pro proximo commit testes relacionados a esses arquivos, e so vai rodar esses testes desses arquivos que estão indo para o proximo commit, para prevenir de rodar todos os testes do sistema "test:staged": "npm test -- --findRelatedTests", # Coverage para obter cobertura de teste, rodamos antes de fazer um push para o github "test:ci": "npm test -- --coverage",
-
No meu .lintstagedrc.json eu coloquei o comando do jest para rodar os testes antes de fazer o commit de arquivos alterados(Somente deles):
{ "*/**/*.{ts,tsx}": [ "eslint src/**/*.{ts,tsx} --fix", "npm run test:staged" ] } -
Na pasta .husky colocamos o arquivo de hook de pre push que roda o script
npm run test:ciantes de fazer o push para o github, que vai gerar a cobertura de testes. Apos colocar isso, não sera possível enviar o push via github desktop, ele da erro de WSL<3>WSL (30) ERROR: CreateProcessParseCommon:708: Failed to translate C:\Users\Pedro\OneDrive\Documentos\GitHub\tdd-clean-architecture-solid <3>WSL (30) ERROR: CreateProcessParseCommon:754: getpwuid(0) failed 2 <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Users\Pedro\AppData\Local\GitHubDesktop\app-3.3.12\resources\app\git\mingw64\libexec\git-core <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Users\Pedro\AppData\Local\GitHubDesktop\app-3.3.12\resources\app\git\mingw64\bin <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Users\Pedro\AppData\Local\GitHubDesktop\app-3.3.12\resources\app\git\usr\bin <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Users\Pedro\bin <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Users\Pedro\AppData\Local\GitHubDesktop\app-3.3.12\resources\app\git\mingw64\bin <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Users\Pedro\AppData\Local\GitHubDesktop\app-3.3.12\resources\app\git\mingw64\usr\bin <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Python312\Scripts <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Python312 <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\WINDOWS\system32 <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\WINDOWS <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\WINDOWS\System32\Wbem <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\WINDOWS\System32\WindowsPowerShell\v1.0 <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\WINDOWS\System32\OpenSSH <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Program Files (x86)\NVIDIA Corporation\PhysX\Common <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Program Files\NVIDIA Corporation\NVIDIA NvDLISR <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\ProgramData\chocolatey\bin <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Users\Pedro\AppData\Roaming\nvm <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Program Files\nodejs <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Program Files\nodejs <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Program Files\Docker\Docker\resources\bin <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Program Files\Git\cmd <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Program Files\Cloudflare\Cloudflare WARP <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Users\Pedro\.console-ninja\.bin <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Users\Pedro\AppData\Local\Microsoft\WindowsApps <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Users\Pedro\AppData\Local\Programs\Microsoft VS Code\bin <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Users\Pedro\AppData\Local\GitHubDesktop\bin <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Users\Pedro\AppData\Roaming\nvm <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Program Files\nodejs <3>WSL (30) ERROR: UtilTranslatePathList:2866: Failed to translate C:\Users\Pedro\AppData\Roaming\npm <3>WSL (30) ERROR: CreateProcessEntryCommon:331: getpwuid(0) failed 2 <3>WSL (30) ERROR: CreateProcessEntryCommon:502: execvpe /bin/bash failed 2 <3>WSL (30) ERROR: CreateProcessEntryCommon:505: Create process not expected to return husky - pre-push script failed (code 1) error: failed to push some refs to 'https://github.com/PedrohvFernandes/tdd-clean-architecture-solid.git'
- Instalando a lib faker, para mocar os dados/valores na parte de teste
npm install --save-dev @faker-js/fakerOnpm i -D faker @types/fakerfoi descontinuado - Devemos fazer as refatorações necessárias/identificado quando o teste esta no verde, antes de começar de escrever o proximo teste
- Modularização dos paths em tsconfig.json
- Agora para o Jest como fazer para resolver esses path, porque foi dito so para o TS
- Enum
jest --clearCacheounpm run test:clearlimpa o cache do jest, caso esteja dando erro de importação de arquivos...- Testes de falha(Caminho triste)
- Últimos testes para o componente RemoteAuthentication
- Testes de sucesso(Caminho feliz)
- Usando o axios para fazer as requisições http
- Criando os mocks separados
- Configurando o React com o Vite. Questões de build, bundler e webpack o vite ja configura por si só, não precisamos nos preocupar com isso.
- Em Jest.config.cjs colocamos o
testEnvironment: 'node'paratestEnvironment: 'jsdom'porque vamos começar a fazer testes que precisa acessar o DOM - Transform ts e tsx
transform: { '.+\\.(ts|tsx)$': 'ts-jest' },- Em eslint
{ // Para resolver um warn do eslint "settings":{ "react":{ "version":"detect" } } // Evitar alguns erros do eslint "extends": [ "plugin:react/recommended", ], "rules": { "react/jsx-uses-react": "off", "react/jsx-uses-vars": "off" } }- Usei o vite em vez do webpack, comparison-vite-webpack-frontend
- Usei o Tailwindcss em vez Sass
- Para que o webpack ? Aprenda A Otimizar Seu Frontend Com Webpack
- Como configurar e fazer o deploy da sua aplicação React do zero usando o Webpack e o Babel
- oque-e-o-babel-e-como-integrar-ele-na-sua-aplicacao-js
- Usando o suporte do babel para o Typescript, você consegue trabalhar com pipelines de build existentes e tem mais chances de gerar JS mais rápido porque o Babel não faz checagem de tipo no seu código.
- O'Que é o Babel e como integrar ele na sua aplicação JS
- Vite vs webpack
- Como substituir webpack & babel por Vite(bundler + compiler(tendo swc como opção)) em um projeto React Typescript legado
- Por que você deve usar swc ? Alternativa de Babel (escrita em Rust) SWC
- Caso de esse erro no jest:
✖ npm run test:staged: ● Validation Error: Test environment jest-environment-jsdom cannot be found. Make sure the testEnvironment configuration option points to an existing node module. Configuration Documentation: https://jestjs.io/docs/configuration As of Jest 28 "jest-environment-jsdom" is no longer shipped by default, make sure to install it separately.De um
npm i jest-environment-jsdom -Dpara resolver o problema Error Test environment jest-environment-jsdom cannot be found- O Husky depois da v5 gera conflitos com o pacote git-commit-msg-linter, para resolver basta criar um arquivo dentro do husky commit-msg e colocar o seguinte comando:
.git/hooks/commit-msg \$1Mais detalhes em: The package is not working with husky v5
npm i -D @testing-library/react
npm i -D jest-localstorage-mockBiblioteca para mockar o localstorage
- Precisei instalar o
ts-jest-mock-import-metapara resolver o erro de import.meta, que não é suportado pelo jest, ja que o vite usa o import.meta para pegar as variáveis de ambiente. E depois no arquivo de configuração do jest, no jest.config.js eu coloquei o plugin para resolver o problema:
{ ## [...] transform: { '^.+\\.tsx?$': [ 'ts-jest', { diagnostics: { ignoreCodes: [1343] }, astTransformers: { before: [ { path: 'node_modules/ts-jest-mock-import-meta', // or, alternatively, 'ts-jest-mock-import-meta' directly, without node_modules. options: { metaObjectReplacement: { url: 'https://www.url.com' } } } ] } } ] } }Solução encontrada em: error TS1343: The 'import.meta' meta-property is only allowed when the '--module' option is 'es2020', 'es2022', 'esnext', 'system', 'node16', or 'nodenext'.
1. Integrando o projeto com TravisCI(tipo um github actions da vida, você pode usar um ou outro para por exemplo fazer o deploy da aplicação e subir os arquivos por exemplo para a Heroku, ou usar um vercel que engloba tudo. So usamos o travisCi para fins didáticos para rodar os testes e o coveralls. Se quiser pode usar TravisCi(Ou o actions) + Vite(no lugar do webpack) + Heroku ou outra solução na doc do vite) e Coveralls
- Nessa aula iremos realizar a integração do projeto com o TravisCI e Coveralls, para que possamos ter um ambiente de integração contínua(continuos integration - CI) e monitoramento de cobertura de testes.
- Criamos uma segunda branch chamada feat/ci
git checkout -b feat/ciele ja cria e muda para ela - Antes de fazer o CI/CD usamos a ferramenta de check, para ver se os pacotes instalados estão atualizados. Instalamos globalmente
npm i -g npm-checke rodamos o comandonpm-checkno terminal do projeto para verificar todos os pacotes do projeto. Podemos rodar o comandonpm-check -u -spara atualizar todos os pacotes do projeto. O -S faz um skip em todos os pacotes que ele diz que não estamos utilizando, como por exemplo o tailwindcss, os types... que nunca importamos diretamente em nosso projeto, e o -U da a opção de atualizar todos os pacotes, para selecionar o pacote que deseja atualizar basta apertar a barra de espaço e depois enter. - Criamos um script para facilitar no check:
"check": "npm-check -u -s"
-
TravisCi - O Travis ira rodar alguns scripts quando dermos um build no projeto, como por exemplo, rodar os testes, verificar se o código esta correto, se esta passando nos testes
- Arquivo de configuração na raiz do projeto travis.yml
- No site do travis permitimos o acesso dele nos repositórios do github ou somente em um repositório especifico ou específicos
- TravisCi
- Nesse link você pode ver todos os repositórios que ele tem acesso
- Após isso é só dar um push
- Deployment Fails with node 20
- Deployment to npm fails with node 20
- Para solucionar The command "npm config set progress false" failed and exited with 1 during . no log do travis Ci por eu colocar uma versão acima de 18 passei a versão 17.9 do node para o yml do travis que é uma pipeline de CI/CD
- TravisCi
-
-
Repos - Ative o repo que deseja monitorar a cobertura de testes
-
Depois Install
yarn add -D coveralls- Depois crie um script no package.json
"test:coveralls": "npm run test:ci && coveralls < coverage/lcov.info",
- A diferença do test:coveralls para o test:ci. É que depois que fizer o build no travis e subir, ele vai gerar o coverage localmente e vai subir esse status para o coveralls.
- O que alimenta o coveralls é o arquivo lcov.info que é gerado na pasta coverage quando rodamos o comando
npm run test:ci, lembrando que ela não vai para o github, pois esta no .gitignore, por isso dentro do comando do coveralls, ele pega esse arquivo gerado, pois passamos para ele o comando npm run test:ci, e ao rodar isso no momento do build pelo travis CI ele gera a pasta coverage com o arquivo lcov.info e sobe esse arquivo para o coveralls através de uma pipe( < coverage/lcov.info). - Para o coveralls funcionar no travis-ci crio o arquivo .coveralls.yml e coloco o token gerado no site do coveralls, para que ele possa subir a cobertura de testes para o site do coveralls. CI/CD With Travis CI and Coveralls in Node/Express API
- Se não fizer isso, irá da esse erro:
Erro de que não encontrou o repositório através do token, para isso basta pegar o token gerado no site do coveralls e criar um arquivo .coveralls.yml na raiz do projeto.C:\Users\Pedro\OneDrive\Documentos\GitHub\tdd-clean-architecture-solid\node_modules\coveralls\bin\coveralls.js:19 throw err; ^ Bad response: 422 {"message":"Couldn't find a repository matching this job.","error":true} (Use `node --trace-uncaught ...` to show where the exception was thrown)
- Para adicionar a chave em um sistema de CI como travis, basta seguir a documentação Coveralls no STEP 3: CONFIGURE YOUR PROJECT TO SEND COVERAGE TO COVERALLS
- Ci services - THE COVERALLS REPO TOKEN (REQUIRED)
- Configuration
- Start measuring code coverage with Jest, Travis CI and Coveralls
- Easy steps to setup Coverage -How to configure Coveralls with Github Action? -Can't get coveralls.io to work with Travis CI and jest
- Pode colocar o token pelo secret do github actions e chamar a secret por ele no arquivo .coveralls.yml(Metodo utilizado no projeto)
- Como usar uma env dentro de um yml, especificamente Coveralls + TravisCi + Jest
- O que alimenta o coveralls é o arquivo lcov.info que é gerado na pasta coverage quando rodamos o comando
-
Caso queira voltar para a branch principal, basta dar um checkout na branch principal
git checkout maine assim para as outras branches -
Damos um marge da branch feat/ci para a branch main
git checkout mainegit merge feat/ci -
Depois damos um push para o github
git push origin main -
E por fim apagamos a branch feat/ci
git branch -D feat/ci -
Durante as aulas agora iremos criar diversas branch para cada aula, para que possamos ter um controle melhor do que foi feito em cada aula, e depois de finalizar a aula, iremos fazer o merge da branch da aula para a branch principal(main), depois apagar a branch da aula e por fim dar um push para a origin main.
-
1. Configurando o Cypress
-
Webpack preprocessor for Cypress - Porque estamos usando TS(Se estiver usando vite não precisa instalar esse)
-
Faça todos essas configurações:
-
Se estiver usando vite faça dessa forma:
-
A pasta do cypress vai criar na raiz, nós movemos para a pasta test dentro do main.
-
Ao rodar
npm run test:cypressele vai abrir o cypress, depois clicamos na opção de E2E Testing depois ira aparecer os testes que ele achar.
Mais um comando para o Git config: `git config --edit --global":
t = !sh -c 'git tag -a $1 -m $1' -
3. Continuous Delivery - Travis CI + Heroku - Não fiz, irei usar a vercel para deploy + vite. So estou usando travisCi para rodar os testes e o coveralls. Deploy na vercel
Comandos usados na aula
# Verificar se tem vulnerabilidades npm audit # Atualizar as dependências npm audit fix
Instalamos o pacote
# Para rodar o cypress usamos o npm run test:cypress ele abre a janela do cypress e depois clicamos em E2E Testing para testar. Agora ao instalar essa lib, usamos o test:cypress:run, ele roda os testes sem abrir a janela do cypress, rodando tudo no terminal, mas para isso funcionar tem que ter um server rodando, no arquivo de config do cypress falamos para escutar a porta 3000 que é a porta que o vite roda o projeto. Então para isso aqui funcionar no ambiente do travisCi, antes de rodar o test do run eu preciso garantir que tenha um server rodando e essa lib que instalamos ela meio que faz de forma, ele cria tipo um loop que fica aguardando até ter o servidor rodando na porta que definimos e so depois disso ele executa o comando. Essa lib é meio que um proxy para você conseguir rodar o script so depois que alguma coisa acontece npm i -D start-server-and-testComandos criados na aula
# Roda o cypress sem abrir a janela do cypress "test:cypress:run": "cypress run" # Roda o cypress sem abrir a janela do cypress, mas antes de rodar ele roda o script start que é o script que inicia o projeto, e so depois que o projeto estiver rodando ele roda o cypress. Usamos o script dev que é o script que inicia o projeto, o vite por si proprio não abre a janela do navegador ao rodar o projeto. Então subiu o servidor, aguardamos o dev rodar e levantar o servidor e a porta 3000 dar um ok, ai ele roda o cypress. Esse comando vai ser rodado no ambiente de CI, ou seja, no travisCi, e tambem no ambiente de desenvolvimento, quando for dar push para o github. Quando for dar o push agora, lembre de fechar a porta 3000 localmente, porque se ela estiver aberta e ao dar push o comando abaixo vai abrir outra porta e o cypress não vai conseguir rodar, pois a porta 3000 ja esta ocupada "test:cypress:ci": "start-server-and-test dev http://localhost:3000 test:cypress:run",
- Vite
- React
- Typescript
- Jest
- Travis
- Coveralls
- Eslint
- Husky
- Lint-staged
- Git-commit-msg-linter
- Conventionalcommits
- Clean Architecture
- Solid
- Faker
- Axios
- Tailwindscss
- Cypress
# Inicia o projeto dev: vite # Builda usando a ferramenta vite build e tsc build: tsc && vite build # Linta o projeto lint: eslint . --ext ts, tsx --report-unused-disable-directives --max-warnings 0 lint:fix: eslint src/**/*.{ts,tsx} --fix preview: vite preview # Testa tudo que for testável test: jest #Do husky prepare: husky
# Instalar dependências npm i # Pre commits npm run prepare # Inicia o projeto npm run dev # Testar o projeto npm run test # Verificar se os arquivos estão em ordem npm run lint npm run lint:fix
- Instalando a lib faker, para mocar os dados/valores na parte de teste