@neetru/cli 2.29.0 → 2.32.0

package/dist/lib/api-error.js

@@ -16,23 +16,29 @@
  *
  * Imprime a mensagem adequada (texto humano ou JSON com `--json`) e encerra o
  * processo — nunca retorna (`never`).
+ *
+ * bug_89d2497e (2026-10-17): o erro de API vira um `NeetruCliError` (cli-kit)
+ * com o exit code da tabela acima e o erro original em `cause`; quem imprime e
+ * encerra é `exitWithCliError`. O formato do JSON e os códigos de saída são os
+ * mesmos de antes. Um `NeetruCliError` que chegue aqui (ex.: lançado dentro do
+ * `try` de um comando) sai com o código DELE, sem ser reclassificado.
  */
 import { CliApiError, CliNetworkError } from './api-client.js';
-import { log } from '../utils/logger.js';
-import { safeExit } from '../utils/safe-exit.js';
-/** Exit codes canônicos, exportados pra teste/documentação. */
-export const API_ERROR_EXIT = {
-    client: 1, // 4xx de input/recurso
-    unauthenticated: 2, // 401
-    forbidden: 3, // 403
-    server: 4, // 5xx / rede / desconhecido
-};
-function emit(json, payload, text) {
-    if (json)
-        console.log(JSON.stringify(payload));
-    else
-        log.error(text);
+import { EXIT_CODES, NeetruCliError } from '../cli-kit/errors.js';
+import { adviseCommand, adviseFlag } from '../cli-kit/command-context.js';
+import { exitWithCliError } from './cli-error.js';
+/**
+ * Reconhece o `SafeExitHalt` de `utils/safe-exit.ts` pela marca, sem importar
+ * `isSafeExitHalt`: dezenas de testes mockam `safe-exit.js` só com `safeExit`,
+ * e ler outra exportação de um mock incompleto lança no vitest.
+ */
+function isSafeExitHalt(x) {
+    return (typeof x === 'object' &&
+        x !== null &&
+        x.__neetruSafeExit === true);
 }
+/** Exit codes canônicos, exportados pra teste/documentação. */
+export const API_ERROR_EXIT = EXIT_CODES;
 /**
  * A mensagem do 401 vale ser exibida? O Core legado mandava só
  * `{ error: 'Unauthorized' }` (o parser vira message='Unauthorized') — aí o
@@ -45,7 +51,30 @@ function isInformative401Message(message) {
         return false;
     return !/^(unauthori[sz]ed|erro http 401)$/i.test(m);
 }
-export function handleApiError(error, json) {
+/**
+ * O que fazer diante de `401 mfa_required`. bug_757b9746 nasceu aqui: o texto
+ * mandava passar `--mfa-token` a qualquer comando, inclusive aos que não
+ * declaravam a flag. Agora a flag só é citada se o comando em execução a
+ * declara; senão, a alternativa que existe sempre — a sessão de 1h.
+ */
+export function mfaRequiredAdvice() {
+    // P105: o comando alternativo também é validado — contra a árvore do
+    // Commander. Sem ele (ou sem árvore conhecida), a dica não o cita.
+    const sessao = (withCommand, withoutCommand) => adviseCommand({ command: 'auth mfa-session', withCommand, withoutCommand });
+    return adviseFlag({
+        flag: '--mfa-token',
+        withFlag: sessao('  Passe --mfa-token <código TOTP> ou rode `neetru auth mfa-session` (sessão de 1h).', '  Passe --mfa-token <código TOTP>.'),
+        withoutFlag: sessao('  Rode `neetru auth mfa-session` (sessão de 1h) e repita o comando.', '  Este comando exige step-up MFA e esta CLI não tem, nele, como enviá-lo.'),
+    });
+}
+/**
+ * Traduz qualquer erro para o `NeetruCliError` canônico — sem imprimir nem
+ * encerrar. Exportado para teste e para quem precise agregar erros de API
+ * como filhos de uma falha parcial.
+ */
+export function cliErrorFromApiError(error) {
+    if (error instanceof NeetruCliError)
+        return error;
     if (error instanceof CliApiError) {
         const s = error.status;
         if (s === 401) {
@@ -54,48 +83,80 @@ export function handleApiError(error, json) {
             // Antes TODO 401 virava "Token inválido ou revogado" — inclusive o de MFA
             // faltando, mandando o operador fazer `neetru login` à toa.
             if (error.code === 'mfa_required') {
-                emit(json, { ok: false, error: 'mfa_required', code: error.code, status: s, message: error.message }, `Step-up MFA exigido: ${error.message}
-` +
-                    '  Passe --mfa-token <código TOTP> ou rode `neetru auth mfa-session` (sessão de 1h).');
-                safeExit(API_ERROR_EXIT.unauthenticated);
+                return new NeetruCliError(error.message, {
+                    code: 'mfa_required',
+                    exit: EXIT_CODES.unauthenticated,
+                    cause: error,
+                    details: { code: error.code, status: s },
+                    human: `Step-up MFA exigido: ${error.message}\n${mfaRequiredAdvice()}`,
+                });
             }
             const serverMsg = isInformative401Message(error.message) ? error.message : '';
-            emit(json, {
-                ok: false,
-                error: 'unauthorized',
-                ...(error.code && error.code !== 'http_401' ? { code: error.code } : {}),
-                status: s,
-                message: error.message,
-            }, serverMsg
-                ? `Não autenticado: ${serverMsg}${/neetru login/.test(serverMsg) ? '' : ' — execute: neetru login'}`
-                : 'Token inválido ou revogado. Execute: neetru login');
-            safeExit(API_ERROR_EXIT.unauthenticated);
+            return new NeetruCliError(error.message, {
+                code: 'unauthorized',
+                exit: EXIT_CODES.unauthenticated,
+                cause: error,
+                details: {
+                    ...(error.code && error.code !== 'http_401' ? { code: error.code } : {}),
+                    status: s,
+                },
+                human: serverMsg
+                    ? `Não autenticado: ${serverMsg}${/neetru login/.test(serverMsg) ? '' : ' — execute: neetru login'}`
+                    : 'Token inválido ou revogado. Execute: neetru login',
+            });
         }
         if (s === 403) {
-            emit(json, { ok: false, error: 'forbidden', status: s, message: error.message }, `Acesso negado: ${error.message}`);
-            safeExit(API_ERROR_EXIT.forbidden);
+            return new NeetruCliError(error.message, {
+                code: 'forbidden',
+                exit: EXIT_CODES.forbidden,
+                cause: error,
+                details: { status: s },
+                human: `Acesso negado: ${error.message}`,
+            });
         }
         if (s >= 400 && s < 500) {
-            emit(json, {
-                ok: false,
-                error: s === 404 ? 'not_found' : (error.code ?? 'client_error'),
-                status: s,
-                message: error.message,
-            }, s === 404
-                ? error.message || 'Recurso não encontrado.'
-                : `Requisição rejeitada (${s}): ${error.message}`);
-            safeExit(API_ERROR_EXIT.client);
+            // Valores válidos de um enum recusado pelo Core (ex.: `environmentId
+            // inválido — use: dev-local | staging | prod.`) vêm no `message` do
+            // próprio Core, que é a fonte que validou: o texto passa inteiro, sem
+            // corte e sem lista copiada do lado de cá.
+            return new NeetruCliError(error.message, {
+                code: s === 404 ? 'not_found' : (error.code ?? 'client_error'),
+                exit: EXIT_CODES.client,
+                cause: error,
+                details: { status: s },
+                human: s === 404
+                    ? error.message || 'Recurso não encontrado.'
+                    : `Requisição rejeitada (${s}): ${error.message}`,
+            });
         }
         // 5xx (incl. 501 — não implementado).
-        emit(json, { ok: false, error: error.code ?? 'server_error', status: s, message: error.message }, `Erro do servidor (${s}): ${error.message}`);
-        safeExit(API_ERROR_EXIT.server);
+        return new NeetruCliError(error.message, {
+            code: error.code ?? 'server_error',
+            exit: EXIT_CODES.server,
+            cause: error,
+            details: { status: s },
+            human: `Erro do servidor (${s}): ${error.message}`,
+        });
     }
     if (error instanceof CliNetworkError) {
-        emit(json, { ok: false, error: 'network', message: error.message }, `Falha de rede: ${error.message}`);
-        safeExit(API_ERROR_EXIT.server);
+        return new NeetruCliError(error.message, {
+            code: 'network',
+            exit: EXIT_CODES.server,
+            cause: error,
+            human: `Falha de rede: ${error.message}`,
+        });
     }
     const message = error instanceof Error ? error.message : String(error);
-    emit(json, { ok: false, error: 'unknown', message }, message);
-    safeExit(API_ERROR_EXIT.server);
+    return new NeetruCliError(message, { code: 'unknown', exit: EXIT_CODES.server, cause: error });
+}
+export function handleApiError(error, json) {
+    // `safeExit` lança `SafeExitHalt` em produção para parar o caller. Dentro de
+    // `try { …; safeExit(n) } catch (e) { handleApiError(e) }` o sinal caía aqui
+    // e virava um segundo erro "[object Object]" — e, em `--json`, uma SEGUNDA
+    // linha de JSON no stdout. A saída já está agendada com o código certo:
+    // o sinal só segue adiante.
+    if (isSafeExitHalt(error))
+        throw error;
+    return exitWithCliError(cliErrorFromApiError(error), json);
 }
 //# sourceMappingURL=api-error.js.map

package/dist/lib/build-targets.d.ts

@@ -0,0 +1,127 @@
+export type PackageManagerName = 'npm' | 'pnpm' | 'yarn' | 'bun';
+export interface PackageManagerInfo {
+    name: PackageManagerName;
+    /**
+     * Diretório onde o `install` deve rodar. Em monorepo é a RAIZ do workspace
+     * (onde mora o lockfile), não o diretório do app — `pnpm install` dentro de
+     * `apps/web` sem o lockfile por perto instala um projeto solto e quebra os
+     * links dos pacotes internos do workspace.
+     */
+    rootDir: string;
+    /** De onde veio a decisão — entra no log pra o dev conseguir auditar. */
+    source: 'campo packageManager' | 'lockfile' | 'default';
+    /** Lockfile encontrado (basename), quando `source === 'lockfile'`. */
+    lockfile?: string;
+}
+/**
+ * `packageManager: "pnpm@9.1.0"` (padrão corepack) → `'pnpm'`.
+ * Qualquer coisa fora do enum conhecido devolve `null` em vez de chutar.
+ */
+export declare function parseCampoPackageManager(valor: unknown): PackageManagerName | null;
+/**
+ * Um diretório só conta como RAIZ DE WORKSPACE se ele se declara como tal.
+ *
+ * Isso é a trava contra o pior modo de falha da subida na árvore: um app em
+ * `~/projetos/meu-app` sem lockfile próprio NÃO pode herdar o
+ * `package-lock.json` que por acaso existe em `~/projetos` — instalar lá
+ * mexeria num projeto que não é o do build.
+ */
+export declare function ehRaizDeWorkspace(dir: string): boolean;
+/**
+ * Descobre QUAL gerenciador de pacote usar e ONDE rodar o `install`, partindo
+ * do diretório do app.
+ *
+ * Ordem de decisão (da mais forte pra mais fraca):
+ *   1. `packageManager` no package.json do próprio app (corepack) — é uma
+ *      declaração explícita do dono do projeto;
+ *   2. lockfile NO PRÓPRIO diretório do app (repo de app único);
+ *   3. subindo a árvore: o primeiro ancestral que tem lockfile **e** se declara
+ *      raiz de workspace (`pnpm-workspace.yaml` ou `workspaces` no package.json).
+ *      O `packageManager` desse ancestral, se houver, vence o lockfile dele;
+ *   4. nada encontrado → `npm` no próprio diretório do app (comportamento
+ *      histórico — não quebra ninguém que já usava o CLI).
+ *
+ * A subida PARA no diretório que contém `.git` (inclusive): fora do repo não
+ * existe workspace que interesse a este build.
+ */
+export declare function detectPackageManager(appDir: string): PackageManagerInfo;
+export interface Comando {
+    cmd: string;
+    args: string[];
+}
+/**
+ * `install` NÃO-DESTRUTIVO por gerenciador.
+ *
+ * bug_93f984a já tinha estabelecido a regra pro npm: nunca `npm ci` (apaga
+ * node_modules e briga com os file locks do `next dev` no Windows). A mesma
+ * regra vale pros outros — nada de `--frozen-lockfile` nem `--immutable`, que
+ * falham de cara quando o dev acabou de mexer num package.json do workspace.
+ */
+export declare function comandoInstall(pm: PackageManagerName): Comando;
+/** Roda um script do package.json (`build`, `start`, …). */
+export declare function comandoRunScript(pm: PackageManagerName, script: string): Comando;
+/**
+ * Executa um binário de `node_modules/.bin` (`next`, `vite`, `tsc`…).
+ *
+ * Usado só no caminho Windows do bug_0cf14fba/bug_893891f, onde o CLI desmonta
+ * o prefixo de env estilo Unix do script e roda o comando real direto. Com pnpm
+ * o `npx` NÃO serve: os binários ficam atrás do store de links do pnpm e o npx
+ * acabaria BAIXANDO o pacote do registry em vez de usar o local.
+ */
+export declare function comandoExecBin(pm: PackageManagerName, bin: string, args: string[]): Comando;
+export interface LayoutStandalone {
+    /** `<appDir>/.next/standalone` — sempre a RAIZ do tar. */
+    standaloneDir: string;
+    /**
+     * Caminho POSIX do app DENTRO do standalone. `''` em repo de app único;
+     * `'apps/web'` num monorepo com `outputFileTracingRoot` na raiz.
+     */
+    appPrefix: string;
+    /** Entrypoint relativo à raiz do tar: `server.js` ou `apps/web/server.js`. */
+    entrypoint: string;
+}
+/**
+ * Acha ONDE o `server.js` do Next.js ficou dentro de `.next/standalone`.
+ *
+ * Em repo de app único ele está na raiz; em monorepo o Next.js aninha o app sob
+ * o caminho dele relativo ao `outputFileTracingRoot` (`apps/web/server.js`).
+ * Não dá pra deduzir esse prefixo do `next.config` (o `outputFileTracingRoot`
+ * pode ser implícito, vindo da detecção de workspace do próprio Next.js), então
+ * a verdade é a árvore PÓS-BUILD — a mesma lógica do `isStandaloneBuildDir`.
+ *
+ * Varredura em largura, pulando `node_modules` (pacote dependente pode ter um
+ * `server.js` qualquer e envenenar a busca). Entre candidatos, ganha o que
+ * TAMBÉM tem um diretório `.next` ao lado — é o par que o Next.js sempre emite
+ * junto (`server.js` + `.next/` com os chunks de servidor). Empate real resolve
+ * pelo mais raso e, em seguida, por ordem alfabética (determinismo: dois builds
+ * da mesma árvore têm que dar o mesmo tarball).
+ *
+ * Devolve `null` quando não há standalone nenhum (build não-standalone) ou
+ * quando há standalone mas nenhum `server.js` — nesse segundo caso quem chama
+ * precisa FALHAR, nunca empacotar um tarball sem entrypoint.
+ */
+export declare function resolveStandaloneLayout(appDir: string): LayoutStandalone | null;
+/**
+ * Resolve o `-C` do `tar` que faz `.next/static` e `public` caírem DENTRO do
+ * prefixo do app no tarball.
+ *
+ * O Next.js não copia nenhum dos dois pro standalone (limitação conhecida), e o
+ * runtime os procura ao lado do `server.js` — ou seja, dentro do prefixo do app,
+ * não na raiz do tar. Era exatamente isso que saía errado em monorepo
+ * (bug_678ddc98): o tar levava `./.next/static` e `./public` na raiz enquanto o
+ * server rodava de `apps/web/`, e o app subia sem CSS/JS e sem os estáticos.
+ *
+ * O truque pra gravar o membro já aninhado SEM `--transform` (GNU) nem `-s`
+ * (bsdtar), que não são portáveis entre os dois tars: o `appPrefix` é, por
+ * construção, `path.relative(outputFileTracingRoot, appDir)` — então o mesmo
+ * caminho EXISTE no disco a partir da raiz de tracing. Basta dar `-C <raiz de
+ * tracing>` e pedir o membro `apps/web/.next/static`, que o tar grava com o
+ * caminho completo.
+ *
+ * Devolve `null` quando o prefixo não casa com o disco (não deveria acontecer —
+ * é a trava contra empacotar caminho inventado).
+ */
+export declare function baseDeInjecaoNoTar(appDir: string, appPrefix: string): {
+    chdir: string;
+    prefixo: string;
+} | null;

package/dist/lib/build-targets.js

@@ -0,0 +1,348 @@
+/**
+ * Detecção de ALVO de build — o diretório do app, o gerenciador de pacote e o
+ * layout do output `standalone` do Next.js.
+ *
+ * bug_678ddc988497475d9160d714a5a10992: o `neetru build` nasceu assumindo
+ * "um repo = um app na raiz = npm". Três premissas, todas cravadas:
+ *
+ *   1. `cwd = process.cwd()` (build.ts:905) — não dava pra apontar pra um app
+ *      dentro de `apps/<app>` sem `cd`;
+ *   2. `npm install` (build.ts:616) e `npm run build` (build.ts:664) literais —
+ *      num repo pnpm/yarn isso resolve o workspace ERRADO (ou nem resolve);
+ *   3. `tarStandalone` assumia `.next/standalone/server.js` no TOPO e injetava
+ *      `.next/static`/`public` na RAIZ do tar (build.ts:412-443), e o
+ *      entrypoint era a string fixa `'server.js'` (build.ts:673).
+ *
+ * Num monorepo (pnpm workspaces + Turborepo) o Next.js, ao tracejar a partir
+ * de `outputFileTracingRoot`, ANINHA o app dentro do standalone:
+ *
+ *   apps/web/.next/standalone/
+ *     node_modules/…            ← fica na RAIZ do standalone (tracejado/hoisted)
+ *     packages/ui/…             ← pacotes do workspace que o app importa
+ *     apps/web/server.js        ← o entrypoint REAL, aninhado
+ *     apps/web/.next/…
+ *
+ * Por isso NÃO dá pra "re-enraizar" o tar em `apps/web`: `server.js` resolve
+ * `node_modules` subindo a árvore, e esses `node_modules` moram ACIMA dele.
+ * O formato correto é preservar a árvore inteira do standalone e apontar o
+ * entrypoint pro caminho aninhado (`apps/web/server.js`), injetando
+ * `.next/static` e `public` DENTRO do prefixo do app.
+ *
+ * Este módulo é propositalmente puro (só `fs` de leitura, zero subprocesso)
+ * pra ser testável sem rodar build nenhum.
+ */
+import * as fs from 'node:fs';
+import * as path from 'node:path';
+/**
+ * Lockfiles conhecidos, em ordem de PRECEDÊNCIA dentro de um mesmo diretório.
+ *
+ * pnpm/yarn/bun vêm antes de npm de propósito: `package-lock.json` é o que mais
+ * aparece por acidente (um `npm install` distraído num repo pnpm gera um), então
+ * ele é o sinal MENOS confiável quando há concorrência. O campo `packageManager`
+ * do package.json (padrão corepack) ganha de todos — ver `detectPackageManager`.
+ */
+const LOCKFILES = [
+    { file: 'pnpm-lock.yaml', name: 'pnpm' },
+    { file: 'yarn.lock', name: 'yarn' },
+    { file: 'bun.lockb', name: 'bun' },
+    { file: 'bun.lock', name: 'bun' },
+    { file: 'package-lock.json', name: 'npm' },
+    { file: 'npm-shrinkwrap.json', name: 'npm' },
+];
+/** Teto de subida na árvore — monorepo nenhum aninha app a 12 níveis da raiz. */
+const MAX_SUBIDA = 12;
+function existe(p) {
+    try {
+        fs.statSync(p);
+        return true;
+    }
+    catch {
+        return false;
+    }
+}
+function lerJson(p) {
+    try {
+        return JSON.parse(fs.readFileSync(p, 'utf8'));
+    }
+    catch {
+        return null;
+    }
+}
+/**
+ * `packageManager: "pnpm@9.1.0"` (padrão corepack) → `'pnpm'`.
+ * Qualquer coisa fora do enum conhecido devolve `null` em vez de chutar.
+ */
+export function parseCampoPackageManager(valor) {
+    if (typeof valor !== 'string')
+        return null;
+    const nome = valor.trim().split('@')[0].toLowerCase();
+    if (nome === 'npm' || nome === 'pnpm' || nome === 'yarn' || nome === 'bun')
+        return nome;
+    return null;
+}
+/**
+ * Um diretório só conta como RAIZ DE WORKSPACE se ele se declara como tal.
+ *
+ * Isso é a trava contra o pior modo de falha da subida na árvore: um app em
+ * `~/projetos/meu-app` sem lockfile próprio NÃO pode herdar o
+ * `package-lock.json` que por acaso existe em `~/projetos` — instalar lá
+ * mexeria num projeto que não é o do build.
+ */
+export function ehRaizDeWorkspace(dir) {
+    if (existe(path.join(dir, 'pnpm-workspace.yaml')))
+        return true;
+    const pkg = lerJson(path.join(dir, 'package.json'));
+    if (!pkg)
+        return false;
+    const ws = pkg.workspaces;
+    // npm/yarn/bun aceitam `workspaces: []` OU `workspaces: { packages: [] }`.
+    if (Array.isArray(ws))
+        return true;
+    if (ws && typeof ws === 'object' && Array.isArray(ws.packages))
+        return true;
+    return false;
+}
+function lockfileDoDir(dir) {
+    for (const lf of LOCKFILES) {
+        if (existe(path.join(dir, lf.file)))
+            return lf;
+    }
+    return null;
+}
+/**
+ * Descobre QUAL gerenciador de pacote usar e ONDE rodar o `install`, partindo
+ * do diretório do app.
+ *
+ * Ordem de decisão (da mais forte pra mais fraca):
+ *   1. `packageManager` no package.json do próprio app (corepack) — é uma
+ *      declaração explícita do dono do projeto;
+ *   2. lockfile NO PRÓPRIO diretório do app (repo de app único);
+ *   3. subindo a árvore: o primeiro ancestral que tem lockfile **e** se declara
+ *      raiz de workspace (`pnpm-workspace.yaml` ou `workspaces` no package.json).
+ *      O `packageManager` desse ancestral, se houver, vence o lockfile dele;
+ *   4. nada encontrado → `npm` no próprio diretório do app (comportamento
+ *      histórico — não quebra ninguém que já usava o CLI).
+ *
+ * A subida PARA no diretório que contém `.git` (inclusive): fora do repo não
+ * existe workspace que interesse a este build.
+ */
+export function detectPackageManager(appDir) {
+    const campoLocal = parseCampoPackageManager(lerJson(path.join(appDir, 'package.json'))?.packageManager);
+    const lockLocal = lockfileDoDir(appDir);
+    // O campo local é a declaração mais explícita que existe — mas o `rootDir`
+    // ainda pode ser um ancestral (app de monorepo que declara `packageManager`
+    // e deixa o lockfile na raiz). Por isso o rootDir é resolvido à parte.
+    if (lockLocal) {
+        return {
+            name: campoLocal ?? lockLocal.name,
+            rootDir: appDir,
+            source: campoLocal ? 'campo packageManager' : 'lockfile',
+            lockfile: campoLocal ? undefined : lockLocal.file,
+        };
+    }
+    let dir = appDir;
+    for (let i = 0; i < MAX_SUBIDA; i++) {
+        const temGit = existe(path.join(dir, '.git'));
+        const pai = path.dirname(dir);
+        if (temGit || pai === dir)
+            break;
+        dir = pai;
+        const lock = lockfileDoDir(dir);
+        if (!lock) {
+            if (existe(path.join(dir, '.git')))
+                break;
+            continue;
+        }
+        // Lockfile de ancestral só vale se o ancestral É raiz de workspace — ver
+        // `ehRaizDeWorkspace` pro porquê (não sequestrar projeto vizinho).
+        if (!ehRaizDeWorkspace(dir))
+            break;
+        const campoRaiz = parseCampoPackageManager(lerJson(path.join(dir, 'package.json'))?.packageManager);
+        return {
+            name: campoLocal ?? campoRaiz ?? lock.name,
+            rootDir: dir,
+            source: campoLocal || campoRaiz ? 'campo packageManager' : 'lockfile',
+            lockfile: campoLocal || campoRaiz ? undefined : lock.file,
+        };
+    }
+    return {
+        name: campoLocal ?? 'npm',
+        rootDir: appDir,
+        source: campoLocal ? 'campo packageManager' : 'default',
+    };
+}
+/**
+ * `install` NÃO-DESTRUTIVO por gerenciador.
+ *
+ * bug_93f984a já tinha estabelecido a regra pro npm: nunca `npm ci` (apaga
+ * node_modules e briga com os file locks do `next dev` no Windows). A mesma
+ * regra vale pros outros — nada de `--frozen-lockfile` nem `--immutable`, que
+ * falham de cara quando o dev acabou de mexer num package.json do workspace.
+ */
+export function comandoInstall(pm) {
+    switch (pm) {
+        case 'pnpm':
+            return { cmd: 'pnpm', args: ['install', '--no-frozen-lockfile'] };
+        case 'yarn':
+            // Serve pro yarn classic (1.x) e pro berry — ambos aceitam `install` puro.
+            return { cmd: 'yarn', args: ['install'] };
+        case 'bun':
+            return { cmd: 'bun', args: ['install'] };
+        case 'npm':
+        default:
+            return { cmd: 'npm', args: ['install', '--no-save', '--no-audit', '--no-fund'] };
+    }
+}
+/** Roda um script do package.json (`build`, `start`, …). */
+export function comandoRunScript(pm, script) {
+    switch (pm) {
+        case 'pnpm':
+            return { cmd: 'pnpm', args: ['run', script] };
+        case 'yarn':
+            return { cmd: 'yarn', args: ['run', script] };
+        case 'bun':
+            return { cmd: 'bun', args: ['run', script] };
+        case 'npm':
+        default:
+            return { cmd: 'npm', args: ['run', script] };
+    }
+}
+/**
+ * Executa um binário de `node_modules/.bin` (`next`, `vite`, `tsc`…).
+ *
+ * Usado só no caminho Windows do bug_0cf14fba/bug_893891f, onde o CLI desmonta
+ * o prefixo de env estilo Unix do script e roda o comando real direto. Com pnpm
+ * o `npx` NÃO serve: os binários ficam atrás do store de links do pnpm e o npx
+ * acabaria BAIXANDO o pacote do registry em vez de usar o local.
+ */
+export function comandoExecBin(pm, bin, args) {
+    switch (pm) {
+        case 'pnpm':
+            return { cmd: 'pnpm', args: ['exec', bin, ...args] };
+        case 'yarn':
+            return { cmd: 'yarn', args: ['exec', bin, ...args] };
+        case 'bun':
+            return { cmd: 'bunx', args: [bin, ...args] };
+        case 'npm':
+        default:
+            return { cmd: 'npx', args: [bin, ...args] };
+    }
+}
+/** Profundidade máxima de varredura dentro do standalone à procura do server.js. */
+const MAX_PROFUNDIDADE_STANDALONE = 6;
+/**
+ * Acha ONDE o `server.js` do Next.js ficou dentro de `.next/standalone`.
+ *
+ * Em repo de app único ele está na raiz; em monorepo o Next.js aninha o app sob
+ * o caminho dele relativo ao `outputFileTracingRoot` (`apps/web/server.js`).
+ * Não dá pra deduzir esse prefixo do `next.config` (o `outputFileTracingRoot`
+ * pode ser implícito, vindo da detecção de workspace do próprio Next.js), então
+ * a verdade é a árvore PÓS-BUILD — a mesma lógica do `isStandaloneBuildDir`.
+ *
+ * Varredura em largura, pulando `node_modules` (pacote dependente pode ter um
+ * `server.js` qualquer e envenenar a busca). Entre candidatos, ganha o que
+ * TAMBÉM tem um diretório `.next` ao lado — é o par que o Next.js sempre emite
+ * junto (`server.js` + `.next/` com os chunks de servidor). Empate real resolve
+ * pelo mais raso e, em seguida, por ordem alfabética (determinismo: dois builds
+ * da mesma árvore têm que dar o mesmo tarball).
+ *
+ * Devolve `null` quando não há standalone nenhum (build não-standalone) ou
+ * quando há standalone mas nenhum `server.js` — nesse segundo caso quem chama
+ * precisa FALHAR, nunca empacotar um tarball sem entrypoint.
+ */
+export function resolveStandaloneLayout(appDir) {
+    const standaloneDir = path.join(appDir, '.next', 'standalone');
+    try {
+        if (!fs.statSync(standaloneDir).isDirectory())
+            return null;
+    }
+    catch {
+        return null;
+    }
+    const candidatos = [];
+    const fila = [
+        { dir: standaloneDir, prefix: '', profundidade: 0 },
+    ];
+    while (fila.length > 0) {
+        const atual = fila.shift();
+        let entradas;
+        try {
+            entradas = fs.readdirSync(atual.dir, { withFileTypes: true });
+        }
+        catch {
+            continue;
+        }
+        const temServer = entradas.some((e) => e.name === 'server.js' && e.isFile());
+        if (temServer) {
+            candidatos.push({
+                prefix: atual.prefix,
+                temNext: entradas.some((e) => e.name === '.next' && e.isDirectory()),
+                profundidade: atual.profundidade,
+            });
+            // Não desce mais por este ramo: achado o app, o que houver abaixo é
+            // output dele, não outro app.
+            continue;
+        }
+        if (atual.profundidade >= MAX_PROFUNDIDADE_STANDALONE)
+            continue;
+        for (const e of entradas) {
+            if (!e.isDirectory())
+                continue;
+            // `node_modules` nunca hospeda o app; `.next` abaixo da raiz é output.
+            if (e.name === 'node_modules' || e.name === '.next')
+                continue;
+            fila.push({
+                dir: path.join(atual.dir, e.name),
+                prefix: atual.prefix ? `${atual.prefix}/${e.name}` : e.name,
+                profundidade: atual.profundidade + 1,
+            });
+        }
+    }
+    if (candidatos.length === 0)
+        return null;
+    candidatos.sort((a, b) => {
+        if (a.temNext !== b.temNext)
+            return a.temNext ? -1 : 1;
+        if (a.profundidade !== b.profundidade)
+            return a.profundidade - b.profundidade;
+        return a.prefix.localeCompare(b.prefix);
+    });
+    const vencedor = candidatos[0];
+    return {
+        standaloneDir,
+        appPrefix: vencedor.prefix,
+        entrypoint: vencedor.prefix ? `${vencedor.prefix}/server.js` : 'server.js',
+    };
+}
+/**
+ * Resolve o `-C` do `tar` que faz `.next/static` e `public` caírem DENTRO do
+ * prefixo do app no tarball.
+ *
+ * O Next.js não copia nenhum dos dois pro standalone (limitação conhecida), e o
+ * runtime os procura ao lado do `server.js` — ou seja, dentro do prefixo do app,
+ * não na raiz do tar. Era exatamente isso que saía errado em monorepo
+ * (bug_678ddc98): o tar levava `./.next/static` e `./public` na raiz enquanto o
+ * server rodava de `apps/web/`, e o app subia sem CSS/JS e sem os estáticos.
+ *
+ * O truque pra gravar o membro já aninhado SEM `--transform` (GNU) nem `-s`
+ * (bsdtar), que não são portáveis entre os dois tars: o `appPrefix` é, por
+ * construção, `path.relative(outputFileTracingRoot, appDir)` — então o mesmo
+ * caminho EXISTE no disco a partir da raiz de tracing. Basta dar `-C <raiz de
+ * tracing>` e pedir o membro `apps/web/.next/static`, que o tar grava com o
+ * caminho completo.
+ *
+ * Devolve `null` quando o prefixo não casa com o disco (não deveria acontecer —
+ * é a trava contra empacotar caminho inventado).
+ */
+export function baseDeInjecaoNoTar(appDir, appPrefix) {
+    if (!appPrefix)
+        return { chdir: appDir, prefixo: '' };
+    const niveis = appPrefix.split('/').filter(Boolean);
+    const chdir = path.resolve(appDir, ...niveis.map(() => '..'));
+    // A igualdade é a prova de que `<chdir>/<appPrefix>` é o MESMO diretório que
+    // `appDir` — sem isso o tar gravaria um caminho que não existe.
+    if (path.resolve(chdir, ...niveis) !== path.resolve(appDir))
+        return null;
+    return { chdir, prefixo: `${appPrefix}/` };
+}
+//# sourceMappingURL=build-targets.js.map