Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
  • Qualcosa non va?
#13,658 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
45/100
Tipo di issue
Funzionalità
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
javascript
Ambito
documentation, tooling

Direzione di ricerca

Inizia ispezionando i metadati di package.json e le cartelle include del package per identificare come sono rappresentati i nomi dei package, gli header principali e gli header privati. Documenta la convenzione snakecase per i nomi dei file, quindi definisci l’ambito della regola di lint e qualsiasi comportamento separato per gli include-guard; il lavoro è completato quando la convenzione è documentata e vengono rilevate le violazioni previste senza segnalare gli include privati.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
JavaScript
Stelle
6k
Fork
1.3k
Merge medio
1g 3h
PR unite (30g)
567

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di stdlib-js/stdlib

Tutte le issue di stdlib-js/stdlib

Issue simili

Altre issue su JavaScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.