DEV Community: Alan Schio

Deja de Ejecutar Toda Tu Suite de Pruebas en Cada Commit 🚫🧪

Alan Schio — Tue, 10 Feb 2026 19:20:56 +0000

Todos hemos pasado por esto. Haces una pequeña corrección en un archivo, haces commit de tus cambios y te quedas viendo cómo toda tu suite de pruebas se ejecuta durante los próximos 5 minutos. ¿Te suena familiar?

¿Y si te dijera que hay una manera de ejecutar solo las pruebas que están realmente relacionadas con tus cambios? Conoce test-staged.

El Problema

Ejecutar toda tu suite de pruebas antes de cada commit es:

⏰ Lento - Desperdiciando tiempo precioso de desarrollo
😤 Frustrante - Rompiendo tu estado de flujo
🔄 Redundante - Probando código que ni siquiera tocaste

La mayoría de los desarrolladores:

Se saltan las pruebas completamente (¡peligroso!)
Esperan largas ejecuciones de pruebas (¡frustrante!)
Hacen push y rezan para que el CI atrape los problemas (¡arriesgado!)

Tiene que haber una mejor manera.

La Solución: test-staged

test-staged es como lint-staged, pero para pruebas. Identifica inteligentemente qué pruebas están relacionadas con tus cambios en stage y ejecuta solo esas.

¿Qué Tan Inteligente Es?

test-staged usa diferentes estrategias dependiendo de tu test runner:

Jest/Vitest: Usa análisis nativo de grafo de dependencias (--findRelatedTests / vitest related)
Mocha/Ava: Mapea inteligentemente archivos fuente a archivos de prueba (ej: user.ts → user.test.ts, src/api/users.ts → src/api/__tests__/users.test.ts)

Empezando en 30 Segundos

La instalación es muy sencilla:

npm install -D test-staged
# o
pnpm add -D test-staged
# o
yarn add -D test-staged
# o
bun add -D test-staged

Y eso es todo. En serio. Es cero configuración por defecto.

Configúralo como un Hook de Pre-Commit

La magia ocurre cuando lo combinas con Husky:

# Instala husky
npm install -D husky
npx husky init

# Agrega test-staged al pre-commit
echo "npx test-staged" > .husky/pre-commit

Ahora cada commit:

✅ Solo ejecutará pruebas relacionadas con tus cambios
⚡ Se completará en segundos en lugar de minutos
🛡️ Bloqueará commits si las pruebas fallan

Ejemplos del Mundo Real

Ejemplo 1: Cambio en un Solo Archivo

Estás trabajando en una funcionalidad de autenticación de usuario:

# Modificaste:
git add src/auth/login.ts

# test-staged ejecuta SOLO:
src/auth/__tests__/login.test.ts
src/integration/__tests__/auth-flow.test.ts  # (porque importa login.ts)

# NO ejecuta:
src/payments/__tests__/*.test.ts  ❌
src/dashboard/__tests__/*.test.ts  ❌
(y más de 200 pruebas no relacionadas)  ❌

Resultado: Las pruebas se completan en 3 segundos en lugar de 2 minutos.

Ejemplo 2: Refactorizando Utilidades

Refactorizaste una función utilitaria:

# Modificaste:
git add src/utils/formatDate.ts

# test-staged automáticamente encuentra TODAS las pruebas que dependen de ella:
src/utils/__tests__/formatDate.test.ts
src/components/__tests__/DatePicker.test.ts
src/pages/__tests__/Dashboard.test.ts

Lo suficientemente inteligente para capturar dependencias indirectas, lo suficientemente rápido para mantenerte productivo.

Ejemplo 3: Soporte para Monorepo

¿Trabajando en un monorepo? test-staged te cubre:

# Estás en packages/ui
git add Button.tsx

# Solo ejecuta:
packages/ui/__tests__/Button.test.tsx

# No ejecuta pruebas de:
packages/api/  ❌
packages/cli/  ❌

Por Qué Te Encantará

🎯 Cero Configuración

Detecta automáticamente:

Tu gestor de paquetes (npm, pnpm, yarn, bun)
Tu test runner (Jest, Vitest, Mocha, Ava)
Tu estructura de proyecto (monorepo o paquete único)

⚡ Extremadamente Rápido

En un proyecto típico con 500+ pruebas:

Antes: 2-3 minutos por commit
Después: 2-5 segundos por commit

Eso es una mejora de 36x en uso del mundo real.

🧠 Realmente Inteligente

Para Jest y Vitest, usa el grafo de dependencias nativo:

// Si cambias userService.ts
// encuentra las pruebas que lo importan:
import { createUser } from './userService'
import { validateUser } from './userService'

Para Mocha y Ava, usa coincidencia de patrones:

src/models/user.ts → src/models/user.test.ts
src/api/users.ts   → src/api/__tests__/users.test.ts
lib/parser.ts      → lib/parser.spec.ts

🛠️ Personalizable Cuando Sea Necesario

Aunque funciona sin configuración, puedes personalizarlo:

// package.json
{
  "test-staged": {
    "runner": "jest",
    "mode": "related",
    "testExtensions": [".test", ".spec", ".e2e"]
  }
}

O crea un .test-stagedrc.json:

{
  "runner": "vitest",
  "testExtensions": [".test", ".spec", "Test", "E2E"]
}

Test Runners Soportados

Runner	Método de Detección
Vitest ⭐	Nativo `vitest related` (grafo de dependencias)
Jest ⭐	Nativo `--findRelatedTests` (grafo de dependencias)
Mocha ✅	Coincidencia de patrones de archivo
Ava ✅	Coincidencia de patrones de archivo

¡Más runners próximamente!

La Experiencia del Desarrollador

Así es como se ve tu flujo de trabajo:

# Haz tus cambios
vim src/components/Button.tsx

# Ponlos en stage
git add src/components/Button.tsx

# Commit (test-staged se ejecuta automáticamente vía hook de pre-commit)
git commit -m "fix: estado hover del botón"

# Salida:
Running tests for staged files...
✓ src/components/__tests__/Button.test.tsx (2 tests) 0.8s

Tests passed! ✨
[main abc1234] fix: estado hover del botón

Sin comandos de prueba manuales. Sin espera. Sin commits rotos.

Preguntas Frecuentes

P: ¿Y si quiero ejecutar todas las pruebas?

R: Solo omite el hook: git commit --no-verify o ejecuta tu suite de pruebas manualmente.

P: ¿Funciona con CI?

R: ¡Sí! Tu CI aún debe ejecutar la suite de pruebas completa. test-staged es para velocidad en desarrollo local.

P: ¿Qué pasa con las pruebas de integración/E2E?

R: test-staged las encontrará si importan tus archivos modificados. También puedes personalizar qué pruebas ejecutar.

P: ¿Puedo usarlo sin hooks de Git?

R: ¡Absolutamente! Solo ejecuta npx test-staged manualmente cuando quieras.

Pruébalo Hoy

Empieza en menos de un minuto:

npm install -D test-staged husky
npx husky init
echo "npx test-staged" > .husky/pre-commit

Luego haz un commit y observa la magia suceder. ✨

Enlaces

En Resumen

Si todavía estás ejecutando toda tu suite de pruebas en cada commit, estás perdiendo tiempo. test-staged te da:

⚡ Commits más rápidos (segundos en lugar de minutos)
🎯 Mejor enfoque (prueba solo lo que cambió)
🛡️ Código más seguro (las pruebas realmente se ejecutan en lugar de ser omitidas)
🚀 Mejor DX (cero configuración, simplemente funciona)

¡Pruébalo y dime qué te parece! Tu yo del futuro te lo agradecerá. 🙌

¿Has probado test-staged? ¿Cuál es tu estrategia actual de pruebas en pre-commit? ¡Comparte en los comentarios abajo! 👇

Pare de Executar Toda a Sua Suite de Testes em Cada Commit 🚫🧪

Alan Schio — Tue, 10 Feb 2026 19:18:09 +0000

Todos nós já passamos por isso. Você faz uma pequena correção em um arquivo, commita suas mudanças e fica assistindo toda a sua suite de testes rodar pelos próximos 5 minutos. Familiar?

E se eu te dissesse que existe uma maneira de executar apenas os testes que estão realmente relacionados às suas mudanças? Conheça o test-staged.

O Problema

Executar toda a sua suite de testes antes de cada commit é:

⏰ Lento - Desperdiçando tempo precioso de desenvolvimento
😤 Frustrante - Quebrando seu estado de fluxo
🔄 Redundante - Testando código que você nem tocou

A maioria dos desenvolvedores:

Pula os testes completamente (perigoso!)
Espera por longas execuções de testes (frustrante!)
Faz push e torce para o CI pegar os problemas (arriscado!)

Tem que haver uma maneira melhor.

A Solução: test-staged

test-staged é como o lint-staged, mas para testes. Ele identifica inteligentemente quais testes estão relacionados às suas mudanças em stage e executa apenas esses.

Quão Inteligente É?

test-staged usa diferentes estratégias dependendo do seu test runner:

Jest/Vitest: Usa análise nativa de grafo de dependências (--findRelatedTests / vitest related)
Mocha/Ava: Mapeia inteligentemente arquivos fonte para arquivos de teste (ex: user.ts → user.test.ts, src/api/users.ts → src/api/__tests__/users.test.ts)

Começando em 30 Segundos

A instalação é moleza:

npm install -D test-staged
# ou
pnpm add -D test-staged
# ou
yarn add -D test-staged
# ou
bun add -D test-staged

E é isso. Sério. É zero configuração por padrão.

Configure como um Hook de Pre-Commit

A mágica acontece quando você combina com o Husky:

# Instale o husky
npm install -D husky
npx husky init

# Adicione test-staged ao pre-commit
echo "npx test-staged" > .husky/pre-commit

Agora cada commit vai:

✅ Executar apenas testes relacionados às suas mudanças
⚡ Completar em segundos ao invés de minutos
🛡️ Bloquear commits se os testes falharem

Exemplos do Mundo Real

Exemplo 1: Mudança em um Único Arquivo

Você está trabalhando em uma funcionalidade de autenticação de usuário:

# Você modificou:
git add src/auth/login.ts

# test-staged executa APENAS:
src/auth/__tests__/login.test.ts
src/integration/__tests__/auth-flow.test.ts  # (porque importa login.ts)

# NÃO executa:
src/payments/__tests__/*.test.ts  ❌
src/dashboard/__tests__/*.test.ts  ❌
(e mais de 200 testes não relacionados)  ❌

Resultado: Testes completam em 3 segundos ao invés de 2 minutos.

Exemplo 2: Refatorando Utilitários

Você refatorou uma função utilitária:

# Você modificou:
git add src/utils/formatDate.ts

# test-staged automaticamente encontra TODOS os testes que dependem dela:
src/utils/__tests__/formatDate.test.ts
src/components/__tests__/DatePicker.test.ts
src/pages/__tests__/Dashboard.test.ts

Inteligente o suficiente para capturar dependências indiretas, rápido o suficiente para te manter produtivo.

Exemplo 3: Suporte a Monorepo

Trabalhando em um monorepo? test-staged te cobre:

# Você está em packages/ui
git add Button.tsx

# Executa apenas:
packages/ui/__tests__/Button.test.tsx

# Não executa testes de:
packages/api/  ❌
packages/cli/  ❌

Por Que Você Vai Amar

🎯 Zero Configuração

Detecta automaticamente:

Seu gerenciador de pacotes (npm, pnpm, yarn, bun)
Seu test runner (Jest, Vitest, Mocha, Ava)
Sua estrutura de projeto (monorepo ou pacote único)

⚡ Extremamente Rápido

Em um projeto típico com 500+ testes:

Antes: 2-3 minutos por commit
Depois: 2-5 segundos por commit

Isso é uma melhoria de 36x no uso do mundo real.

🧠 Realmente Inteligente

Para Jest e Vitest, usa o grafo de dependências nativo:

// Se você mudar userService.ts
// ele encontra testes que o importam:
import { createUser } from './userService'
import { validateUser } from './userService'

Para Mocha e Ava, usa correspondência de padrões:

src/models/user.ts → src/models/user.test.ts
src/api/users.ts   → src/api/__tests__/users.test.ts
lib/parser.ts      → lib/parser.spec.ts

🛠️ Personalizável Quando Necessário

Embora funcione sem configuração, você pode customizá-lo:

// package.json
{
  "test-staged": {
    "runner": "jest",
    "mode": "related",
    "testExtensions": [".test", ".spec", ".e2e"]
  }
}

Ou crie um .test-stagedrc.json:

{
  "runner": "vitest",
  "testExtensions": [".test", ".spec", "Test", "E2E"]
}

Test Runners Suportados

Runner	Método de Detecção
Vitest ⭐	Nativo `vitest related` (grafo de dependências)
Jest ⭐	Nativo `--findRelatedTests` (grafo de dependências)
Mocha ✅	Correspondência de padrões de arquivo
Ava ✅	Correspondência de padrões de arquivo

Mais runners em breve!

A Experiência do Desenvolvedor

Veja como fica seu fluxo de trabalho:

# Faça suas mudanças
vim src/components/Button.tsx

# Coloque em stage
git add src/components/Button.tsx

# Commit (test-staged executa automaticamente via hook de pre-commit)
git commit -m "fix: estado hover do botão"

# Saída:
Running tests for staged files...
✓ src/components/__tests__/Button.test.tsx (2 tests) 0.8s

Tests passed! ✨
[main abc1234] fix: estado hover do botão

Sem comandos de teste manuais. Sem espera. Sem commits quebrados.

Perguntas Comuns

P: E se eu quiser executar todos os testes?

R: Apenas pule o hook: git commit --no-verify ou execute sua suite de testes manualmente.

P: Funciona com CI?

R: Sim! Seu CI ainda deve executar a suite de testes completa. test-staged é para velocidade no desenvolvimento local.

P: E quanto a testes de integração/E2E?

R: test-staged vai encontrá-los se eles importarem seus arquivos modificados. Você também pode customizar quais testes executar.

P: Posso usar sem hooks do Git?

R: Absolutamente! Apenas execute npx test-staged manualmente quando quiser.

Experimente Hoje

Comece em menos de um minuto:

npm install -D test-staged husky
npx husky init
echo "npx test-staged" > .husky/pre-commit

Depois faça um commit e veja a mágica acontecer. ✨

Resumindo

Se você ainda está executando toda sua suite de testes em cada commit, está desperdiçando tempo. test-staged te dá:

⚡ Commits mais rápidos (segundos ao invés de minutos)
🎯 Melhor foco (teste apenas o que mudou)
🛡️ Código mais seguro (testes realmente executam ao invés de serem pulados)
🚀 Melhor DX (zero configuração, simplesmente funciona)

Experimente e me diga o que você achou! Seu eu do futuro vai te agradecer. 🙌

Você já experimentou test-staged? Qual é sua estratégia atual de testes em pre-commit? Compartilhe nos comentários abaixo! 👇

Stop Running Your Entire Test Suite on Every Commit 🚫🧪

Alan Schio — Tue, 10 Feb 2026 19:15:59 +0000

We've all been there. You make a small fix in one file, commit your changes, and watch as your entire test suite runs for the next 5 minutes. Sound familiar?

What if I told you there's a way to run only the tests that are actually related to your changes? Enter test-staged.

The Problem

Running your complete test suite before every commit is:

⏰ Slow - Wasting precious development time
😤 Frustrating - Breaking your flow state
🔄 Redundant - Testing code you didn't even touch

Most developers either:

Skip tests entirely (dangerous!)
Wait through long test runs (frustrating!)
Push and pray the CI catches issues (risky!)

There has to be a better way.

The Solution: test-staged

test-staged is like lint-staged, but for tests. It intelligently identifies which tests are related to your staged changes and runs only those.

How Smart Is It?

test-staged uses different strategies depending on your test runner:

Jest/Vitest: Uses native dependency graph analysis (--findRelatedTests / vitest related)
Mocha/Ava: Intelligently maps source files to test files (e.g., user.ts → user.test.ts, src/api/users.ts → src/api/__tests__/users.test.ts)

Getting Started in 30 Seconds

Installation is a breeze:

npm install -D test-staged
# or
pnpm add -D test-staged
# or
yarn add -D test-staged
# or
bun add -D test-staged

And that's it. Seriously. It's zero-config by default.

Set Up as a Pre-Commit Hook

The magic happens when you combine it with Husky:

# Install husky
npm install -D husky
npx husky init

# Add test-staged to pre-commit
echo "npx test-staged" > .husky/pre-commit

Now every commit will:

✅ Only run tests related to your changes
⚡ Complete in seconds instead of minutes
🛡️ Block commits if tests fail

Real-World Examples

Example 1: Single File Change

You're working on a user authentication feature:

# You modified:
git add src/auth/login.ts

# test-staged runs ONLY:
src/auth/__tests__/login.test.ts
src/integration/__tests__/auth-flow.test.ts  # (because it imports login.ts)

# NOT running:
src/payments/__tests__/*.test.ts  ❌
src/dashboard/__tests__/*.test.ts  ❌
(and 200+ other unrelated tests)  ❌

Result: Tests complete in 3 seconds instead of 2 minutes.

Example 2: Refactoring Utilities

You refactored a utility function:

# You modified:
git add src/utils/formatDate.ts

# test-staged automatically finds ALL tests that depend on it:
src/utils/__tests__/formatDate.test.ts
src/components/__tests__/DatePicker.test.ts
src/pages/__tests__/Dashboard.test.ts

Smart enough to catch indirect dependencies, fast enough to keep you productive.

Example 3: Monorepo Support

Working in a monorepo? test-staged has you covered:

# You're in packages/ui
git add Button.tsx

# Only runs:
packages/ui/__tests__/Button.test.tsx

# Doesn't run tests from:
packages/api/  ❌
packages/cli/  ❌

Why You'll Love It

🎯 Zero Configuration

It automatically detects:

Your package manager (npm, pnpm, yarn, bun)
Your test runner (Jest, Vitest, Mocha, Ava)
Your project structure (monorepo or single package)

⚡ Lightning Fast

On a typical project with 500+ tests:

Before: 2-3 minutes per commit
After: 2-5 seconds per commit

That's a 36x speed improvement in real-world usage.

🧠 Actually Intelligent

For Jest and Vitest, it uses the native dependency graph:

// If you change userService.ts
// it finds tests that import it:
import { createUser } from './userService'
import { validateUser } from './userService'

For Mocha and Ava, it uses pattern matching:

src/models/user.ts → src/models/user.test.ts
src/api/users.ts   → src/api/__tests__/users.test.ts
lib/parser.ts      → lib/parser.spec.ts

🛠️ Customizable When Needed

While it works out-of-the-box, you can customize it:

// package.json
{
  "test-staged": {
    "runner": "jest",
    "mode": "related",
    "testExtensions": [".test", ".spec", ".e2e"]
  }
}

Or create a .test-stagedrc.json:

{
  "runner": "vitest",
  "testExtensions": [".test", ".spec", "Test", "E2E"]
}

Supported Test Runners

Runner	Detection Method
Vitest ⭐	Native `vitest related` (dependency graph)
Jest ⭐	Native `--findRelatedTests` (dependency graph)
Mocha ✅	File pattern matching
Ava ✅	File pattern matching

More runners coming soon!

The Developer Experience

Here's what your workflow looks like:

# Make your changes
vim src/components/Button.tsx

# Stage them
git add src/components/Button.tsx

# Commit (test-staged runs automatically via pre-commit hook)
git commit -m "fix: button hover state"

# Output:
Running tests for staged files...
✓ src/components/__tests__/Button.test.tsx (2 tests) 0.8s

Tests passed! ✨
[main abc1234] fix: button hover state

No manual test commands. No waiting. No broken commits.

Common Questions

Q: What if I want to run all tests?

A: Just bypass the hook: git commit --no-verify or run your test suite manually.

Q: Does it work with CI?

A: Yes! Your CI should still run the full test suite. test-staged is for local development speed.

Q: What about integration/E2E tests?

A: test-staged will find them if they import your changed files. You can also customize which tests run.

Q: Can I use it without Git hooks?

A: Absolutely! Just run npx test-staged manually whenever you want.

Try It Today

Get started in less than a minute:

npm install -D test-staged husky
npx husky init
echo "npx test-staged" > .husky/pre-commit

Then make a commit and watch the magic happen. ✨

The Bottom Line

If you're still running your entire test suite on every commit, you're wasting time. test-staged gives you:

⚡ Faster commits (seconds instead of minutes)
🎯 Better focus (test only what changed)
🛡️ Safer code (tests actually run instead of being skipped)
🚀 Better DX (zero config, just works)

Give it a try and let me know what you think! Your future self will thank you. 🙌

Have you tried test-staged? What's your current pre-commit testing strategy? Share in the comments below! 👇

Mastering Nuxt hooks - Disable SSG default pages (200, 400) .

Alan Schio — Thu, 23 Jan 2025 14:23:20 +0000

Nuxt is an awesome framework, build on top of another awesome framework, Vue, with a powerful structure that cover mostly everything you want and need, it allows you to do both, SPA, SSR and SSG.

Nuxt's Static Site Generation provider a set of default pages to help you, (root) index.html, 200.html and 400.html.
But image the case: you need to get rid of 200 and 400, for any reason like you need to merge nuxt generated pages into a already in production page/application (e.g. PHP legacy code and Nuxt new generated pages).

But these pages are hardcoded into Nuxt, so how would we avoid to get rid of then?

We can of course do a rm 200.html for example after the build, but lets image this scenario:

A legacy application that you are page by page migrating to Nuxt, using SSG facilitates your work because it will generate the same PHP/NGNIX structure: base HTTP directory driven routing.

Perform the build and after the rm 200.html rm 404.html rm index.html can be a pain and even may not work as expected: if we have the same pages on the legacy application root.

At Nuxt discussion page we can see a entry related to it Disable 200.html and 404.html #18831, but the solution there do not work.

You may think _"not a problem i can extend the routes and remove then". Well... that not work cuz they aren't a route on your project, and this happens in a lower layer than routes, on nitro. Nitro is the web server that powers Nuxt, but you probably already know that.

Till today (Jan/24/2025) Nuxt has not yet got it into its docs: https://nuxt.com/docs/guide/concepts/rendering#deploying-a-static-client-rendered-app and states that these pages are default with no option to undo that:

The Solution

After dig a little into the Nuxt's code, we can see the are add into the Nitro's hook: 'prerender:routes', this hook Taking a look into nitro pre render hook interface we can see it has a skip property, and its implementation is pretty straight forward and what we are lookin for:

\\ https://github.com/nitrojs/nitro/blob/main/src/core/prerender/prerender.ts
    // Check if route is skipped or has errors
    if (_route.skip || _route.error) {
      await nitro.hooks.callHook("prerender:route", _route);
      nitro.logger.log(formatPrerenderRoute(_route));
      dataBuff = undefined; // Free memory
      return _route;
    }

With that knowledge we can safely skit the generation of this files by doing at your nuxt.config.ts

export default defineNuxtConfig({
  ssr: false,
  nitro: {
    hooks: {
      "prerender:generate"(route) {
        const routesToSkip = ['/200.html', '/404.html']; 
        if (routesToSkip.includes(route.route) ) {
          route.skip = true;
        }
      },
    },
  },
})

In my case i even need the general root index on it: const routesToSkip = ['/200.html', '/404.html', 'index.html'];

And now we have a SSG dist generation without the default Nuxt pages:

Deploy to Fly.io with bitbucket-pipelines

Alan Schio — Wed, 28 Aug 2024 00:25:48 +0000

It is easy to find integrations for Github or GitLab, but i spent a couple of minutes trying to make it work, so why no sharing?

Create Fly Token

First go to your Fly.io App and create a Deploy Token (https://fly.io/apps/your-app/tokens)

Let the Expiration if you want it to never expires

Add a Repository Variable

Now go to your bitbucket repository settings, under Pipeline side menu, at Repository Variables (https://bitbucket.org/YOURORG/YOURPROJECT/YOURREPO/pipelines/repository-variables).
And create a new variable with the name FLY_API_TOKEN.

Create the pipeline file

Now create your bitbucket-pipelines.yml file and use the golang image so you can install the flyctl and deploy your app.

image: golang:1.15
pipelines:
  default:
    - step:
        name: Deploy to Fly.io
        deployment: production
        script:
          - apt-get update -qq && apt-get install -y curl
          - curl -L https://fly.io/install.sh | sh
          - export FLYCTL_INSTALL="/root/.fly"
          - export PATH="$FLYCTL_INSTALL/bin:$PATH"
          - flyctl deploy

Converting snake_case to camelCase with vscode

Alan Schio — Wed, 17 Jul 2024 19:02:53 +0000

Open the find/replace and click on the .*
In the first input use _([a-zA-Z])
In the second use \U$1

Now just convert everything and be happy converting SQL/JSON to object variables/params or anything else.

Nem tudo precisa de Micro Frontends, as vezes você só precisa de Web Components

Alan Schio — Mon, 01 Jul 2024 13:01:48 +0000

Micro Frontends se tornaram uma das Buzzwords mais atrativas do desenvolvimento frontend moderno, e não é por menos, soluções como o Module Federation trouxeram uma possibilidade que foi procurada por aproximadamente 10 anos e fez o "Micro Services" de fato funcionar no frontend.

Mas Micro Frontends, assim como mono-repos, não é uma bala de prata, uma solução para toda e qualquer problema. A maior parte dos casos que necessitam de fato de Micro Frontends são por questões organizacionais, escalabilidade ou aplicações que precisam crescer, talvez rapido demais, e que agora precisam ser quebradas para serem "feitas do jeito certo".
Não vou negar, eu gosto muito de Micro Frontends, não é a toa que fiz meu mestrado em cima do tema, o primeiro no Brasil, mostrando seu uso na prática solucionando um problema de mais de 3 anos na mais importante empresa de agronegócio do país. Mas será que você precisa mesmo de Micro Frontends?

Alguns meses atrás auxiliei um amigo num impasse sobre isso: "Alan precisamos de uma solução de integração e tudo que eu vejo nos direciona para micro frontends", o cenário:
Múltiplas aplicações, em diferentes frameworks, algumas até sem framework, precisam ter um mesmo componente, digamos que algo que gerencia a autenticação do usuário, uma espécie de "SSO".
Você certamente está pensando que isso é o caso mais óbvio e claro de Micro Frontends, e nisso eu te pergunto, como você vai fazer para integrar casos que não utilizam Webpack/Vite, ouu até mesmo um bundler/builder? Fazer o RequireJS, JQuery, Backbone, Ember, AngularJS (v1),Vue versões 1, 2 e 3, Nuxt, React, e aplicações que utilizem PHP ou JS, e em alguns casos até aplicações Desktop com Electron… ajustar tudo para usar micro frontends? Imagine ter que adaptar build, adicionar bundler, ajustar roteamento de servidor… e mais um mundaréu de coisas para usar Microfrontends…. Viu nem sempre o óbio é tão óbvio.

Então eu te pergunto: que tecnologia existe que "rode" em todos os navegadores e que seria possível utilizar em todos os casos acima? Claro, JavaScript + HTML, e que maneira você possui de fazer isso de forma otimizada, encapsulada e que possa ser compartilhado independente de bundler, até mesmo utilizando importações e links diretos? Web Components, eu sei que além disso você está pensando, mas eu vou ter que "copiar" esse componente para dentro de TODAS as aplicações, vai ser o mesmo "inferno" toda vez um trabalho manual, quando atualizar ou mudar a versão… O problema da modernidade é que pensamos que ela resolve problemas que nós mesmo criamos. Antigamente quando "tudo era mato" na internet, toda solução de problema era: HTML + JavaScript e CDN. E acreditem, essa continua sendo uma solução mágica.

Você precisa de uma solução ou componente que rode em qualquer aplicação web independente de framework ou render? Web Components.
Você precisa compartilhar esse componente em tempo real sem a necessidade de atualizar suas aplicações quando atualizar uma versão? Content Delivery Network - CDN.

Nada de avançado, novo ou absurdo, apenas utilizando tudo o que já existe na Web, da maneira correta.

Refactoring function signature maintaining backward compatibility

Alan Schio — Wed, 29 May 2024 14:09:56 +0000

Have you ever see yourself with a function (or method, depending on programming language) that has too many arguments and would be a lot better to switch to a single options/params/item object?
This can be stressfull or painfull depending on all the regressions or usages of this functions. Even sometimes it can be a blind spot to how much that function is being used.

But no fear my friend, Rest Operators are here to save you! 🦸

Imagine you have an add to cart function:

const addItemToCart = (productId, quantity, size) => {
// ommited for god's sake
}

Time (and developers) goes by and we need to add more items to it, but it have so many usages that a refactor will be a hell of a work... After some years this function found itself as

const addItemToCart = (productId, quantity, size, hasPromotion, addedFrom, cartId, someOtherInfo) => {
}

You wish you could change to a simple const addItemToCart = (itemData) => but that will make a simple task grows to a hell of a regressions and files to update, right?

Well let's start a painless refactor:

1 - of course change the functions arguments to be a single one:

const addItemToCart = (itemData) => {
}

2 - let convert this argument to use Rest Operators:

const addItemToCart = (...itemData) => {
}

3 last but not least let's apply conditional validation to use the arguments data:

const addItemToCart = (...itemData) => {
  let item = {};
  if (typeof itemData[0] === 'object') {
    item = itemData[0];    
  else {
    const [
      productId,
      quantity,
      size,
      hasPromotion,
      addedFrom,
      cartId,
      someOtherInfo
    ] = itemData;
    item = {
      productId,
      quantity,
      size,
      hasPromotion,
      addedFrom,
      cartId,
      someOtherInfo
    };
  }
}

And now all old keeps working and you can start write new function call with a prettier code 😉

Selenium Webdriver - how to bypass server's basic authentication popup

Alan Schio — Fri, 22 Dec 2023 12:09:28 +0000

Are you entering on E2E/Automated test world with selenium-webdriver and had faced this issue:

You need to access a page which has basic authentication popup, a secure server.

Well research and found how to do this was a little harsh, so this is a quick guide for you to don't suffer like i did.

The secret is the createCDPConnection. With selenium-webdriver we need to get to the browser api and perform a register


const { Builder, By } = require('selenium-webdriver');
const Chrome = require('selenium-webdriver/chrome');
const assert = require("assert");
const url = `https://my.server.com/`

describe('Server with basic auth', function () {

  before(async function () {
    driver = await new Builder().forBrowser('chrome').build();
  });

  beforeEach(async () => {
// this is what does the trick
    const connection = await driver.createCDPConnection('page');
    await driver.register("username", "password", connection);
// now you can go the url safety
    await driver.get(url);
  })


  it('Bypass the popup', async function () {
    const message = await driver.findElement(By.className("heading")).getText();
    assert.equal('Welcome!', message);
  })
  after(function () {
   await driver.quit()
  })
})

Testing Hooks on Vue 2 (or Options API)

Alan Schio — Wed, 27 Sep 2023 20:39:00 +0000

Have you ever spent hours thinking how could you test a method called on mount?
First lets say we have this component:

export default {
  name: 'MyCustomComponent',
  mounted() {
    this.calledOnMount()
  },
  methods: {
    calledOnMount() {}
  }
}

We want to make sure the calledOnMount will be called, using @vue/test-utils and vitest/jest there are two main ways to test validate it:

toHaveBeenCalled
toBeCalled

But the work with a spy function and usually we write tests like this:

import { mount } from '@vue/test-utils'
import MyCustomComponent from '../MyCustomComponent.vue'

describe('MyCustomComponent.vue', () => {
  const wrapper = mount(MyCustomComponent)
  spyOn(wrapper.vm, 'calledOnMount')
})

When calling the mount it already runs the mounted lifecicly, so, even adding a spy it will always fail.

toHaveBeenCalled -> we can't intercept the mount proccess to add a spy on here
toBeCalled -> the function has already be called

But calm down, there is a way to test it, for sure!
We had to bind the spy by accessing the .vue component and its options.methods such:

import MyCustomComponent from '../MyCustomComponent.vue'
type MyCustomComponentType = {
  options: { methods: { calledOnMount: () => void } }
}
vi.spyOn(
  (MyCustomComponent as unknown as MyCustomComponentType).options.methods,
  'calledOnMount'
)

This way you dont have to intercept the wrapper functions, but the component signature function.
Once the mounted component is like a new "instance" of a "class" component, the spy we add on the .vue, will also works with the mounted component on test.

describe('MyCustomComponent.vue', () => {
  const wrapper = mount()
  it('Should remove scroll event listener on destroy', async () => {
    expect(
      (MyCustomComponent as unknown as MyCustomComponentType).options.methods
        .calledOnMount
    ).toHaveBeenCalled()
  })
})

Now you can easy test your functions and everything you do on mount.

Vue and Input File - Clear File or Select same file

Alan Schio — Wed, 21 Jun 2023 20:28:58 +0000

Have you ever had the case where ou have a file selector component, you clear the file model but then you can't select the same file again?

Codepen: https://codepen.io/schirrel/pen/YzRGrvq

Well its kinda hard and curious to explain.
First of all to the TL/DR:
You need to use Vue's $refs and set the input to null.

Now if you want to understand why, let's pass thru some important stuff:

First: Vue doesn't work with v-model and file input, even has a discussion about it on the offical Vue's repo: Discussion.

Now lets undestand why doesnt work, two main things:

input with type="file" only triggers change event, while v-model listen to input event.
v-model needs to set the value html attribute, if you ever try to do :value="myFileModel" this error will show up:

Error in nextTick: "InvalidStateError: Failed to set the 'value' property on 'HTMLInputElement': This input element accepts a filename, which may only be programmatically set to the empty string.

So with this comes a question: how to a clear a file, and most important, how make it possible to select again?

Lets paint a simple use case: You have your own file wrapper the uses a file input (obviously) but you save the file on the data. Example:

<template>
 <label for="inputFile">
      Click here to select you file
      <input type="file" name="inputFile" id="inputFile" @change="selectFile" />
    </label>
    <span v-if="file">
      File Selected {{ file.name }}
      <button @click="clearFile">remove</button>
    </span>
</template>
<script>
export default {
  data() {
    return {
      file: null
    };
  },
  methods: {
    selectFile(event) {
      this.file = event.target.files[0];
    },
    clearFile() {
      this.file = null;
    }
  }
};
</script>

Even if clearFile is setting file as null, when selecting the file again the @change wont be triggered again. Thats why because the html value attribute still the same, the file prop on data doesn't affect it. Take a look at the codepen example.

Once we have seen that :value don't work with files, the proper way to do this is acessing the HTML <input type="file" /> and reset this value programmatically.

By adding a ref="fileInput" to the <input> and inside the clearFile method add:

this.$refs.fileInput.value = null

Now it works:

The codepen final solution: https://codepen.io/schirrel/pen/XWyjeOw

Note: this is common behavior across frameworks;

Create a Nuxt Bridge App

Alan Schio — Wed, 21 Jun 2023 19:26:24 +0000

Even tho the Nuxt docs is pretty good, i hadn't found a single tutorial on creating a nuxt bridge app, so why not create right? Docs is good, but sometimes is need a more straight forward thing!

Step 1 - Create a Nuxt 2 App

yarn create nuxt-app nuxt-bridge-app`

You can select the config of your app as you like, mine was:

After install we can run execute yarn dev and see the app running

Step 2 - Upgrade to latest Nuxt 2

As stated at the migration docs we need to use the latest Nuxt 2 release, so far today (16/03/2023) the version is 2.16.2.
We replace the version on package.json and once again execute yarn install, now our main dependencies are:

"nuxt": "2.16.2",
"vue": "2.7.10",

Step 3 - Install Nuxt Bridge

The docs says to install as

yarn add --dev @nuxt/bridge@npm:@nuxt/bridge-edge

Step 4 - Update scripts at package.json

Now we are going to use nuxi instead of nuxt to run and build the app.
At your package.json replace the content at the script's prop to:

"scripts": {
   "dev": "nuxi dev",
   "build": "nuxi build",
   "start": "nuxi preview"
  }

Step 5 - Update Nuxt config

Now update the nuxt.config file to use Nuxt Bridge, import defineNuxtConfig from '@nuxt/bridge' and wrap it arount the config object:

import { defineNuxtConfig } from '@nuxt/bridge'

export default defineNuxtConfig({
  // Your existing configuration
})

If you are using typescript you need to add the below line at your tsconfig:

 "extends": "./.nuxt/tsconfig.json"

And disable typescript from bridge at nuxt.config file to avoid conflict between the Ts on bridge and on your configuration:

bridge: {
    typescript: false
  },

Now you can simply run again yarn dev and now you are using Nuxt Bridge on you project

The source code is on https://github.com/schirrel/nuxt-bridge-app

DEV Community: Alan Schio

Deja de Ejecutar Toda Tu Suite de Pruebas en Cada Commit 🚫🧪

El Problema

La Solución: test-staged

¿Qué Tan Inteligente Es?

Empezando en 30 Segundos

Configúralo como un Hook de Pre-Commit

Ejemplos del Mundo Real

Ejemplo 1: Cambio en un Solo Archivo

Ejemplo 2: Refactorizando Utilidades

Ejemplo 3: Soporte para Monorepo

Por Qué Te Encantará

🎯 Cero Configuración

⚡ Extremadamente Rápido

🧠 Realmente Inteligente

🛠️ Personalizable Cuando Sea Necesario

Test Runners Soportados

La Experiencia del Desarrollador

Preguntas Frecuentes

Pruébalo Hoy

Enlaces

En Resumen

Pare de Executar Toda a Sua Suite de Testes em Cada Commit 🚫🧪

O Problema

A Solução: test-staged

Quão Inteligente É?

Começando em 30 Segundos

Configure como um Hook de Pre-Commit

Exemplos do Mundo Real

Exemplo 1: Mudança em um Único Arquivo

Exemplo 2: Refatorando Utilitários

Exemplo 3: Suporte a Monorepo

Por Que Você Vai Amar

🎯 Zero Configuração

⚡ Extremamente Rápido

🧠 Realmente Inteligente

🛠️ Personalizável Quando Necessário

Test Runners Suportados

A Experiência do Desenvolvedor

Perguntas Comuns

Experimente Hoje

Links

Resumindo

Stop Running Your Entire Test Suite on Every Commit 🚫🧪

The Problem

The Solution: test-staged

How Smart Is It?

Getting Started in 30 Seconds

Set Up as a Pre-Commit Hook

Real-World Examples

Example 1: Single File Change

Example 2: Refactoring Utilities

Example 3: Monorepo Support

Why You'll Love It

🎯 Zero Configuration

⚡ Lightning Fast

🧠 Actually Intelligent

🛠️ Customizable When Needed

Supported Test Runners

The Developer Experience

Common Questions

Try It Today

Links

The Bottom Line

Mastering Nuxt hooks - Disable SSG default pages (200, 400) .

The Solution

Deploy to Fly.io with bitbucket-pipelines

Create Fly Token

Add a Repository Variable

Create the pipeline file

Converting snake_case to camelCase with vscode

Nem tudo precisa de Micro Frontends, as vezes você só precisa de Web Components

Refactoring function signature maintaining backward compatibility

Selenium Webdriver - how to bypass server's basic authentication popup

Testing Hooks on Vue 2 (or Options API)

Vue and Input File - Clear File or Select same file

Create a Nuxt Bridge App

Step 1 - Create a Nuxt 2 App

Step 2 - Upgrade to latest Nuxt 2

Step 3 - Install Nuxt Bridge