Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[2.0] refactor component for specificcomponent types

オープン
  • 何か問題がありますか？
#1,024 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
35/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
静か
技術スタック
json
領域
data

調査の方向性

リンクされている2つの仕様プルリクエストから始めて、現在のコンポーネント定義を見つけてください。コンポーネント参照と型固有の要件がどのように使用されているかを追跡してください。コンポーネントがベース定義と型固有の定義に分割され、サポートされるコンポーネント型が oneOf で表現され、下流のプロパティ処理が明示的なままになっていれば完了です。

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

説明

CDX 2.0

after

the current component should be split in

  • baseComponent - core properties of a component
  • serviceComponent - inherit from baseComponent and add service-specific properties and requirements
  • softwareComponent - inherit from baseComponent and add {application,framework,library,...}-specific properties and requirements
  • hardwareComponent - inherit from baseComponent and add service-specific properties and requirements
  • fileComponent - inherit from baseComponent and add file-specific properties and requirements
  • dataComponent - inherit from baseComponent and add data-specific properties and requirements
  • ... and so on - for each component type

I would even put the baseComponent, serviceComponent, etc ... under /$defs/component/$defs/,
not under /$defs/

after that split, the current component becomes a oneOf ala

{
  "$defs": {
    "component" : {
      "oneOf": [
         {"$ref": "#$defs/component/$defs/serviceComponent"}
         {"$ref": "#$defs/component/$defs/hardwareComponent"},
         {"$ref": "#$defs/component/$defs/...Component"},
       ],

       "$defs": {
         "baseComponent": {
           "$comment": "This is a mixin. make sure to use `unevaluatedProperties` in the usage downstream"
           "type": "object",
           "required": [ ... ] 
           "properties": {
             "type": { "enum": ["service", "device", ...] }, 
             "bom-ref": ...,
             "parties": ...
             "group": ...,
             "name": ...,
             "description": ...,
             "version": ...,
             "versionRange": ..., 
             "isExternal": ..., 
             ...
             "components": { "$ref": "#$defs/components" }
           }
         },
         "serviceComponent": {
           "allOf": [{ "$ref": "#/$defs/component/$defs/baseComponent" }],
           "titile": "Service Component",
           "type": "object",
           "required": ["endpoint", ...]
           "properties": {
             "type": { "enum": ["service"] },
             // service-specific properties
             "endpoint": ...,
             "isExternal": { "default": true }, 
             ...
             "components": { "$comment": "opportunity: make all items requiring a certain `type`" }
           },
           "unevaluatedProperties": false
         },
         "...Component": { ... },
       } 
    }
  }


}
主要言語
XSLT
スター
558
フォーク
93
平均マージ
14時間 57分
マージ済み PR（30日）
22

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

CycloneDX/specification のほかの issue

CycloneDX/specification の issue をすべて見る

似ている issue

Data Engineering の issue をもっと見る

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

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