voseo-check

Detecta voseo rioplatense en las líneas que agregas. Sin configuración, sin dependencias, sin archivos nuevos en la raíz.

Solo reporta. No reescribe tus archivos: la corrección la decide quien escribió el texto.

⚠️ 2 posible(s) voseo(s) argentino(s):

  docs/guia.md:1  «tenés» → tienes
    Si tenés dudas, hacelo igual.
  docs/guia.md:1  «hacelo» → tuteo de «haz» + «lo»
    Si tenés dudas, hacelo igual.

Uso

npx voseo-check

Sin argumentos elige el modo solo:

| Contexto | Qué revisa | |---|---| | CI de GitHub sobre un PR | el diff contra la base del PR | | Hay algo en el índice | lo que está staged (pre-commit) | | Rama con base detectable | el diff contra origin/HEAD, develop, main o master | | Nada de lo anterior | todos los archivos |

Con un merge sin resolver, git deja los archivos en conflicto fuera del diff: la revisión lo avisa y no los da por limpios.

Por defecto solo mira líneas añadidas. Un repo con voseo previo arrancaría en rojo y nadie volvería a mirarlo; revisando lo que entra, el problema se drena commit a commit.

Acotar a una ruta

npx voseo-check docs/              # solo docs/, modo autodetectado
npx voseo-check docs/ src/ --all   # todo el contenido de esas rutas
npx voseo-check README.md          # un archivo suelto

Funciona sin git: sobre una carpeta cualquiera recorre el filesystem.

Auditar todo

npx voseo-check --all

Integración

npx voseo-check init

Pregunta qué instalar:

Revisar antes de cada commit (pre-commit)? [S/n]
Revisar antes de cada push (pre-push)? [s/N]
Agregar el workflow de CI para los pull requests? [S/n]

Qué abarca la revisión?
  1) solo lo que cambia (recomendado)
  2) todo el proyecto
> 1

Debe fallar el build cuando encuentra voseo? [s/N]

Es idempotente: no pisa lo que ya exista, y agrega su línea a un hook existente sin reemplazarlo. El hook usa el gestor del repo — pnpm dlx, yarn dlx, bunx o npx— según packageManager o el lockfile.

Sin terminal —CI, scripts— no pregunta: aplica los defaults, o las banderas.

npx voseo-check init --pre-push --scope all --strict --yes

| Bandera | Default | |---|---| | --pre-commit / --no-pre-commit | instalado | | --pre-push / --no-pre-push | no instalado | | --ci / --no-ci | instalado | | --scope diff\|all | diff | | --strict | avisa, no bloquea | | --yes | pregunta si hay terminal |

En CI, a mano

- uses: actions/checkout@v4
  with: { fetch-depth: 0 }
- uses: bsantosio/voseo-check@v1

fetch-depth: 0 hace falta para que exista la rama base con la que comparar. Para que falle el build en vez de avisar, with: { strict: "true" }.

Qué garantiza un check verde. La configuración se lee del árbol que se está revisando, así que un pull request puede ampliar su propio ignore o allow y pasar limpio. Es la misma propiedad que tienen eslint o prettier, y no se puede cerrar sin dejar de leer la configuración del repositorio: si te importa, revisa los cambios a package.json como revisas cualquier otro. Y usa pull_request, nunca pull_request_target: con ese evento el código del fork correría con permisos de escritura y acceso a los secrets.

Sin la action, equivalente:

- run: npx --yes voseo-check --github

En el hook

pnpm dlx voseo-check --staged --quiet || true   # o npx --yes / yarn dlx / bunx

Configuración

Toda opcional. Vive en package.json, para no sumar otro archivo a la raíz:

{
  "voseo": {
    "ignore": ["docs/legacy/**", "CHANGELOG.md"],
    "terms":  { "cachái": "entiendes" },
    "allow":  ["dale"],
    "strict": true
  }
}

En repos sin package.json (docs, Go, Python), lo mismo en voseo.config.json.

• ignore — rutas a excluir, sintaxis tipo .gitignore con globstar y negación. Binarios, lockfiles y directorios de build ya se excluyen solos.
• terms — términos propios, además del diccionario base.
• allow — términos del diccionario base que este repo acepta.
• strict — falla en vez de avisar.

Escape puntual

Un ejemplo de voseo: "tenés". <!-- voseo-ok -->

Opciones

--staged            solo el índice
--base <ref>        diff contra una referencia git
--all               todos los archivos, no solo el diff
--strict            sale con código 1 si hay hallazgos
--format text|json  formato de salida
--github            anotaciones de GitHub Actions
--quiet             silencio si no hay hallazgos

--format json sirve para consumirlo desde otra herramienta:

{
  "mode": "all",
  "count": 1,
  "findings": [
    { "file": "docs/guia.md", "line": 1, "term": "hacelo",
      "fix": "tuteo de «haz» + «lo»", "kind": "clitic", "snippet": "..." }
  ]
}

Qué detecta

Solo formas inequívocas: una forma entra al diccionario únicamente si no colisiona con ninguna palabra válida del español neutro. Por eso no hay un patrón genérico /\w+ás\b/ — el futuro de tuteo (harás, podrás) y palabras comunes (además, inglés, quizás) caerían adentro.

Exclusiones deliberadas:

| Caso | Por qué | |---|---| | abrí, seguí, escribí, viví | homógrafos del pretérito: yo abrí el archivo es correcto | | creé, pasé, dejé | idem: yo creé el registro | | dale | imperativo de tuteo válido: dale el archivo a Juan | | acá, plata, auto, celular | léxico compartido con otras variedades, incluida la chilena |

Con enclítico esas mismas raíces sí se marcan (abrime, escribime, decime), porque ahí la ambigüedad desaparece: nadie escribe "yo abrime".

Si algo se te cuela o sobra, terms y allow están para eso.

API

import { detectInText } from 'voseo-check'

detectInText('tenés que verlo')
// → [{ term: 'tenés', fix: 'tienes', kind: 'term' }]

kind distingue qué tipo de reescritura pide cada hallazgo: term tiene un reemplazo directo, clitic depende del verbo irregular (hacelo es hazlo, no hácelo) y advice es una indicación, no un reemplazo.

Licencia

MIT