Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[RFC]: Add lint support for enforcing header filename conventions

Abierto
  • ¿Algo no está bien?
#13,658 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@kanikasharma-18 ya está trabajando en esto.

Desde el 20/9/2026.

  • #15369 de @kanikasharma-18 — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
javascript
Área
documentation, tooling

Línea de trabajo

Empieza inspeccionando los metadatos de package.json y las carpetas de include del paquete para identificar cómo se representan los nombres de los paquetes, los headers principales y los headers privados. Documenta la convención de nombres de archivo en snakecase y, después, define el alcance de la regla de lint y cualquier comportamiento separado de include-guard; el trabajo se considera terminado cuando la convención está documentada y se detectan las infracciones previstas sin marcar los includes privados.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

A package's primary header file and its include guard needs to match the package name, except for being in snakecase, rather than kebabcase.

We have this convention so that end users have a consistent rule for how to convert a package name to a header include path. If packages are allowed to deviate from that convention, end users would need to explicitly look up the include path for each package they wanted to use, which just creates unnecessary friction.

We should both (a) document and (b) create a lint rule for enforcing filenames and potentially support separate linting for enforcing include guards (although this may be tied to us getting clang linting up and running).

When linting filenames, we'd need to distinguish between the main include and additional includes which are intended to be private. For the latter, these are allowed to have any name (e.g., see ndarray/base/unary). What should be the case is that if a package has an include folder, there should always be a header file having a path matching the package name, with the file basename being the base package name converted to snakecase. I cannot think of an exception to this rule. And if we ever needed to make an exception, we could consider, at some point in the future, adding an associated config option to a package's package.json which allows disabling the lint rule.

Created via /stdlib todo from stdlib-js/stdlib#11830 by @kgryte.

Lenguaje dominante
JavaScript
Estrellas
6k
Forks
1.3k
Merge medio
1 d 10 h
PR fusionados (30 d)
568

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de stdlib-js/stdlib

Todos los issues de stdlib-js/stdlib

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.