WebComponentsのような新しいテクノロジーの台頭により、開発者がプロジェクトで使用するHTML(タグ、ネスト、属性の増加)が増えるにつれて、HTML Linterを追加(および拡張)することが重要になると思います。
https://github.com/rcorp/standard-project-structure/issues/4での調査によると、
HTMLhintはそこにある最高のものです。 標準の.htmlhintrc
ファイルはどうですか?
使用されるルールはどのように選択されますか? 標準的なルールのいくつかは本当に個人的な好みです。 例えば:
https://github.com/yaniswang/HTMLHint/wiki/Attr-value-double-quotesはどちらも完全に有効なHTML5であり、この定型文でデフォルトのスタイルを選択する必要はないと思います。
https://github.com/yaniswang/HTMLHint/wiki/Tag-self-close両方とも有効なHTML5であり、後者は実際にはXHTMLの場合と同様に、より現代的な方法であり、下位互換性のためにHTML5で許可されています私の知る限り、XHTMLからHTML5に移行するとき。
https://github.com/yaniswang/HTMLHint/wiki/Attr-value-not-emptyどちらも有効で、後者はほとんどの人が使用するものですが、悪い方法と見なされています。
これらのルールの多くは疑わしいものであり、ボイラープレートの一部がエラーまたは警告としてマークされる原因になります。 そのため、私はこれを追加することに反対しており、むしろそのような設定は開発者に任せて、このプロジェクトにバンドルしないようにしたいと思います。 たぶん、ドキュメントにHTMLリンターセクションを追加して、さまざまなリンターへのリンクを提供しますか?
@quantumpacket tag-self-close
おっしゃったように、どちらかを選択することには常に少なくともある程度の正当性があり、ボイラープレートの内容と同じようにコミュニティが検討できる場所ではありませんか? 正当化がない場合は、単にそのルールを追加しません。 参考までに、JS https://github.com/rcorp/standard-project-structure/issues/6、特にAirBNBのすべてのコードスタイルを見ると、多くのルールがあることがわかりますが、それぞれに開発者が高く評価する推論。
私は完全にあなたの主張を理解しますが、これらは単なるルールです。 私たちが選択しないものは強制されません。 したがって、これは非常に寛大なアプローチになる可能性があります。 開発者が.htmlhintrc
からルールを追加/削除するための定型文
@ gaurav21rこれを
どの値を選択するかについては、プロジェクト自体から開始点が明らかになります。 @quantumpacket sharedの例の場合、二重引用符を使用し、空の属性を使用し、自己終了しません。 そこから、きっと人々の意見が出てくると思います。
@roblarsenPRで貢献したいと思います。 ルールセットの適切な開始ベースをすでに選択しています。 https://github.com/rcorp/standard-project-structure/issues/13
いくつかの大きな組織で使用されています。 それが定型文と一致し、あまり意見がないかどうかを確認します。 残りはPR自体で話し合うことができます!
この問題に関する進展はありますか?
@ gaurav21r更新はありますか? いいえの場合、他の誰かがこれを突き刺したいですか?
@roblarsen @ gaurav21rが続行できない場合は、喜んで対応させていただきます。
@AlexxNicaはいいですね。 私たちはいつも助けが大好きです。
返信が遅くなってすみません! @ roblarsen @ AlexxNicaこれを15日までに実行しようとします。 そうでない場合は、誰でも喜んでお手伝いします!
心配ない!
15日が過ぎ去りました! これは、それをやりたいと思っている人なら誰でも参加できます。
HTMLHintが最良の選択肢であると確信していますか?
@AlexxNica私はこの面での経験が
プロジェクトにコードを追加する前に、これをよく確認する必要があります。 アクションを実行する前に確認する必要があること:
・実装の必要性を正当化するのに十分役立ちますか?
・発送・保守は簡単ですか?
・誰か/私たちによってテストされましたか?
・実際のモデルよりも実際に改善が見られますか?
・アナライザーに準拠するために何も変更する必要がないかどうかを確認するために、コードに対してテストを実行しましたか? (ユーザーがモニターに表示できるよりも多くのエラーが画面に表示されないようにするため)
・長期的な存在感はありますか? (一定期間存在しないものを実装するのは良い考えではないと思います)
・その使いやすさは何ですか?
@roblarsenこれのラベルを変更することを検討できますか? 「 awaiting feedback
」と(多分)「 HTML
」の方が適切だと思います。
それらを追加しました。 それはまだ助けが必要であり、まだ新しい機能です。 私はこれに個人的に触れるつもりはないので、それは間違いなくコミュニティが実行しなければならないものです。
ここには2つの質問があると思います。
ユーザーのsrc / distフォルダーに.htmlhintrc
を含める必要がありますか?
HTMLHintは、コンパイルされた完全なHTMLページをリントするためにのみ使用することを目的としています(たとえば、デフォルトでは、すべてのファイルに<title>
タグがあることを確認するため、ほとんどのサーバー側またはテンプレート言語にはあまり適していません。したがって、多くのユーザーがAngular、React、PHP、ASP、またはLiquidのようなテンプレート言語を使用しているため、価値が限られていると思います。多くのエラーが発生するか、まったく機能しません。ユーザーはすべてのルールを編集して、エラーが表示されないようにすることができます。しかし、そうすると、それを含めるという目的が損なわれます。すべてのユーザーがIDEを使用できるようにするには、プラグインをインストールする必要があります。十分な数のユーザーが、インクルードなしで純粋なHTMLでWebページをコーディングしているとは思いません。その包含(私は個人的にHTML電子メールをコーディングするときにHTMLHintのみを使用します-バグを見つけるのに最適です)-そしてJSまたはCSSのリンター/ヒンター構成ファイルを含めません。
エラーをチェックするために、ビルドシステムにHTMLHintを含める必要がありますか?
はい、これは良い考えかもしれないと思います。 私たちのビルドシステムは現在Gulpを使用しており、統合するためのNPMパッケージがあります: //www.npmjs.com/package/gulp-htmlhint。 これについては、数日中に調べます。 これにより、コンパイル時にHTMLエラーがチェックされ、サイトを展開する前に問題を見つけるのに役立ちます。
テンプレート言語でhtmlリンターを使用できないことは、常にそれを使用することを妨げていました。 jsxはESLintで効果的にリントできるので、Reactは少し別の話です。
リンティングビルドはプロジェクトにとっては有益であるように見えますが、エンドユーザーにとってはそうではありません。 しかし、何もないよりはましだと思われます。少なくとも、ボイラープレートのソースで時折発生するエラーを防ぐことができます。
ところで、そのような些細なタスクにGulpを使用する理由はわかりません。 リンターの追加レイヤーを回避し、 npm test
から直接呼び出す方が常に簡単で信頼性が高くなります(例を参照)。
IMO、非標準のツールには近づかないでください。
バリデーターをまったく使用していないようなものです。Bootstrapv4-devでは基本的に実際のエラーをキャッチしなかったhtmlhintに切り替えていたので、経験から話しています。
私の提案は、Javaが必要な場合でも、公式のバリデーターvnu.jarを使用することです。 Javaが利用可能な場合にそれを実行するラッパースクリプトを持つことができます。
私は最近、Bootstrap(https://github.com/twbs/bootstrap/pull/24149を参照)で同様の変更を行いました。これは、基本的にhtmlhintによる検証が行われていないことに悩まされたためです。
残念ながら、HTMLHintはアクティブに維持されなくなり(https://github.com/yaniswang/HTMLHint)、@ XhmikosRが言うように、問題があるので、この問題を解決することに投票します。
コオロギ+上記
最も参考になるコメント
@roblarsenPRで貢献したいと思います。 ルールセットの適切な開始ベースをすでに選択しています。 https://github.com/rcorp/standard-project-structure/issues/13
いくつかの大きな組織で使用されています。 それが定型文と一致し、あまり意見がないかどうかを確認します。 残りはPR自体で話し合うことができます!