stdlib-js / stdlib-js/stdlib

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

オープン
#13,658 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る
主要言語
JavaScript
スター
6k
フォーク
1.3k
平均マージ
1日 3時間
マージ済み PR(30日)
611

説明

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](https://github.com/stdlib-js/stdlib/pull/11830) by @kgryte.*

コントリビューションガイド

コントリビューションガイドを開く

調査の方向性

Start by inspecting the package.json metadata and package include folders to identify how package names, primary headers, and private headers are represented. Document the snakecase filename convention, then define the lint rule's scope and any separate include-guard behavior; done means the convention is documented and the intended violations are detected without flagging private includes.

索引モデルが issue の本文から書いたものです。

評価

技術スタック
javascript
領域
documentation, tooling
issue の種類
機能追加
難易度
5/5
見積もり時間
1週間以上
活発さ
静か
明瞭さ
おおむね明確
初心者へのやさしさ
45/100

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。