Este conversor separa HTTPServerConfig em HTTP, Server e Config?

Não. A regra de detecção de limite de palavra usada (minúscula seguida de maiúscula) não captura a transição entre duas maiúsculas consecutivas, então HTTPServer inteiro é tratado como um único token. O resultado em snake_case é httpserver_config, não http_server_config.

Por que userName converte corretamente para user_name, mas HTTPServer não separa como esperado?

Porque em userName a transição é de minúscula (r) para maiúscula (N), exatamente o padrão que a regra de detecção reconhece. Em HTTPServer, a transição entre as maiúsculas consecutivas (P para S) não é uma transição de minúscula para maiúscula, então não aciona a divisão.

Vale testar um conversor de case com identificadores que contêm siglas antes de usá-lo num pipeline automatizado?

Sim. Identificadores simples (sem sigla) costumam converter de forma previsível em qualquer implementação, mas siglas expõem o comportamento específico da regra de detecção de limite de palavra usada — testar com exemplos reais do seu domínio (userID, parseURL) antes de confiar o resultado a um processo automatizado evita surpresas.

Conversor de Case para Código

Documentação técnica

Conversor de Case: detectar limites de palavra é o problema real, não a formatação final

Converter entre camelCase, PascalCase, snake_case e kebab-case parece, à primeira vista, um problema de formatação simples — mas a parte não trivial do algoritmo é anterior à formatação: detectar corretamente onde uma palavra termina e outra começa dentro de uma string sem delimitador explícito. Este conversor identifica limites de palavra com uma regra objetiva — uma letra minúscula (ou dígito) imediatamente seguida de uma maiúscula, via a expressão regular /([a-z0-9])([A-Z])/ — além dos delimitadores óbvios (underscore, hífen, espaço). Essa regra cobre corretamente o caso comum: userName vira user + Name, porque o "r" minúsculo é seguido do "N" maiúsculo.

Onde essa regra específica encontra seu limite: siglas

A regra "minúscula seguida de maiúscula" não cobre a transição entre duas letras maiúsculas consecutivas — então um identificador com sigla, como HTTPServerConfig, não é dividido em HTTP + Server + Config. O que acontece, na prática, é que HTTPServer inteiro vira um único token (httpserver), porque a transição P→S é maiúscula-maiúscula (não capturada pela regra), e só a transição seguinte, "r" minúsculo para "C" maiúsculo, aciona a divisão — o resultado final é httpserver_config em snake_case, não http_server_config. É um comportamento consistente e prático para a maioria dos identificadores do dia a dia, mas vale conhecer esse limite específico se o texto de entrada tiver siglas — o resultado não separa a sigla da palavra seguinte automaticamente.

Por que isso importa em geração de código a partir de schema

Ferramentas de refatoração e geradores de código a partir de schema (por exemplo, gerar nomes de propriedade em camelCase para TypeScript a partir de colunas snake_case de um banco) dependem dessa mesma lógica de segmentação. Testar a conversão com identificadores que contêm siglas reais do seu domínio (userID, parseURL, HTTPStatusCode) antes de confiar o resultado a um pipeline automatizado é a forma direta de descobrir se esse limite específico afeta o seu caso de uso — em vez de só testar com identificadores simples, sem sigla, que sempre convertem de forma previsível.