Resolvendo Erro Ao Iniciar Whatsapp-web.js

by Admin 43 views
Resolvendo erro ao iniciar whatsapp-web.js

E aí, galera! Se você tá aqui, é porque provavelmente se deparou com aquele erro chato: "TypeError: Cannot read properties of null (reading '1')" logo de cara ao tentar iniciar seu script com whatsapp-web.js. Cara, eu sei como é frustrante, a gente quer que tudo funcione redondinho e aí PÁ! Um erro que parece grego. Mas relaxa, meu chapa, que a gente vai desvendar isso juntos!

Esse erro, especificamente, geralmente tá ligado a como a biblioteca tenta acessar ou processar arquivos de cache ou manifestos durante a inicialização do Puppeteer. Pensa comigo: o whatsapp-web.js usa o Puppeteer pra controlar uma instância do navegador (o Chrome, no caso) que vai simular o WhatsApp Web. Pra isso funcionar de boa, ele precisa de uns arquivos que ajudam a gerenciar a sessão, o cache, e tudo mais. Quando algo dá errado nesse processo de leitura desses arquivos, ele pode acabar tentando ler algo que não existe ou que veio corrompido, jogando esse erro aí.

Entendendo o Erro em Detalhes

Vamos dar uma olhada mais de perto no stack trace que você compartilhou:

C:\Users\yuri1\Desktop\whatsapp\2\whatsapp-api\node_modules\whatsapp-web.js\src\webCache\LocalWebCache.js:34
        const version = indexHtml.match(/manifest-([\d\\.]+)\.json/)[1];
                                                                    ^

TypeError: Cannot read properties of null (reading '1')
    at LocalWebCache.persist (C:\Users\yuri1\Desktop\whatsapp\2\whatsapp-api\node_modules\whatsapp-web.js\src\webCache\LocalWebCache.js:34:69)
    at C:\Users\yuri1\Desktop\whatsapp\2\whatsapp-api\node_modules\whatsapp-web.js\src\Client.js:744:36
    at process.processTicksAndRejections (node:internal/process/task_queues:95:5)

O ponto crucial está aqui: indexHtml.match(/manifest-([\d\\.]+)\.json/)[1]. Essa linha tá tentando encontrar um padrão em uma string chamada indexHtml e extrair um grupo específico (o [1]). O problema é que indexHtml.match(...) retornou null, o que significa que o padrão /manifest-([\d\\.]+)\.json/ não foi encontrado na string indexHtml. E aí, ao tentar acessar [1] de um null, o JavaScript te dá esse belo TypeError.

Por que isso pode acontecer? Várias coisas, mano:

  1. Cache Corrompido ou Incompleto: O whatsapp-web.js tenta otimizar o carregamento do WhatsApp Web usando um cache local. Se esse cache estiver corrompido, desatualizado, ou se o processo foi interrompido de forma abrupta antes, o arquivo indexHtml (ou o que ele espera encontrar) pode não estar como deveria.
  2. Mudanças no WhatsApp Web: O WhatsApp Web é uma aplicação web que o Facebook (Meta) atualiza constantemente. Essas atualizações podem mudar a estrutura dos arquivos HTML, JavaScript, ou os nomes dos manifestos, quebrando a forma como o whatsapp-web.js tenta encontrá-los.
  3. Configuração do Puppeteer: Às vezes, as configurações que você passa para o Puppeteer podem interferir na forma como ele carrega os recursos da página, incluindo os arquivos de cache que o whatsapp-web.js procura. As opções de sandbox, proxy, ou até mesmo o timeout podem, em casos raros, causar problemas.
  4. Ambiente de Execução: Problemas com permissões de escrita no diretório onde o cache é salvo, ou conflitos com outros processos no seu sistema, também podem ser a causa.

A Solução Rápida: Limpando o Cache e Ajustando as Configurações

A primeira coisa que a gente geralmente tenta nesses casos é limpar a bagunça do cache. O whatsapp-web.js, por padrão, salva um diretório chamado .wwebjs_auth (ou algo similar, dependendo da versão e configuração) na raiz do seu projeto. Esse diretório contém informações de autenticação e cache. Deletar esse diretório força o whatsapp-web.js a baixar tudo de novo, como se fosse a primeira vez.

Passo 1: Delete o Diretório de Cache

No seu terminal, navegue até a pasta do seu projeto (whatsapp-api no seu caso) e execute:

# No Linux/macOS
rm -rf .wwebjs_auth

# No Windows (prompt de comando)
rmdir /s /q .wwebjs_auth

# No Windows (PowerShell)
Remove-Item -Recurse -Force .wwebjs_auth

Importante: Ao fazer isso, você vai precisar escanear o QR code novamente da próxima vez que iniciar o script, pois as informações de autenticação serão perdidas. É um pequeno preço a pagar pela solução, né?

**Passo 2: Ajustando o Código (O que você já fez!)

Você já fez um ótimo trabalho ao tentar ajustar as configurações do Puppeteer. A linha que você adicionou no seu código // Desativar o cache local completamente não está diretamente no código que você postou, mas a intenção é boa. O whatsapp-web.js não tem uma opção direta para desativar o cache de forma simples, mas podemos tentar outras abordagens.

Olha só o código que você apresentou:

const { Client, NoAuth } = require('whatsapp-web.js');
const express = require('express');
const qrcode = require('qrcode-terminal');
// const fs = require('fs'); // Descomente se precisar usar fs

const app = express();
const port = 3000;

const client = new Client({
    authStrategy: new NoAuth(),
    puppeteer: {
        headless: true,
        args: [
            '--no-sandbox',
            '--disable-setuid-sandbox',
            '--disable-dev-shm-usage',
            '--disable-accelerated-2d-canvas',
            '--no-first-run',
            '--no-zygote',
            '--single-process',
            '--disable-gpu',
            '--proxy-server="direct://"',
            '--proxy-bypass-list=*'
        ],
        timeout: 60000 // Ajusta o tempo limite para 60 segundos
    }
});

// ... restante do código ...

client.initialize();
// ... restante do código ...

As configurações que você usou para o Puppeteer são bem agressivas e visam rodar em ambientes restritos (como Docker ou servidores sem interface gráfica). Essas configurações podem ser a causa do problema, pois elas forçam o navegador a rodar de uma maneira não padrão, o que pode afetar como ele carrega os recursos e como o whatsapp-web.js interage com eles.

Vamos tentar uma abordagem um pouco mais simples para o Puppeteer, mantendo o headless: true que você precisa para rodar em servidor, mas talvez removendo algumas das flags mais extremas, ou testando com elas.

Possível Ajuste 1: Simplificando as Flags do Puppeteer

Tente rodar com um conjunto mais básico de flags. Às vezes, menos é mais.

const client = new Client({
    authStrategy: new NoAuth(),
    puppeteer: {
        headless: true,
        args: [
            '--no-sandbox',
            '--disable-setuid-sandbox',
            '--disable-dev-shm-usage'
            // Mantenha outras flags se forem estritamente necessárias para seu ambiente
        ],
        // timeout: 60000 // O timeout pode ser útil, mas vamos testar sem ele por um momento
    }
});

Possível Ajuste 2: Ignorando o Cache (Não é uma opção direta, mas podemos forçar a recriação)

Como mencionei, não há um ignoreCache: true direto. A melhor forma de