@citolab/tspci 2.11.0 → 2.12.0

package/CHANGELOG.md

@@ -3,6 +3,17 @@
 All notable changes to this project will be documented in this file.
 See [Conventional Commits](https://conventionalcommits.org) for commit guidelines.
 
+# [2.12.0](/compare/v2.11.0...v2.12.0) (2026-08-19)
+
+
+### Features
+
+* include the SBOM in the exported package by default 376b89a
+
+
+
+
+
 # [2.11.0](/compare/v2.10.0...v2.11.0) (2026-08-19)
 
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@citolab/tspci",
-  "version": "2.11.0",
+  "version": "2.12.0",
   "description": "an opiniated typescript ims-pci builder with tao integration",
   "author": "patrick <patrick.deklein@cito.nl>",
   "repository": "@citolab/tspci",
@@ -55,5 +55,5 @@
     "access": "public",
     "registry": "https://registry.npmjs.org/"
   },
-  "gitHead": "ad0858f9b665b6778cdf19685e858e167847e930"
+  "gitHead": "eb7676525e9bf75daa9b2f42f035faed9b8e9a70"
 }

package/readme.md

@@ -85,8 +85,9 @@ For more info: [@citolab/tspci-qti3](https://github.com/Citolab/tspci/tree/main/
 ### SBOM
 
 Every production build (`tspci`, `tspci --target ...`) writes a [CycloneDX](https://cyclonedx.org/) 1.6
-SBOM to `dist/sbom.cdx.json`. When you export a package, a copy is placed next to the package as
-`<package-name>.sbom.cdx.json`, so you keep one SBOM per released version.
+SBOM to `dist/sbom.cdx.json`. A package export puts it in two places: inside the package next to the
+bundle it describes, and next to the package as `<package-name>.sbom.cdx.json` so you keep one SBOM per
+released version for your own technical documentation.
 
 The SBOM is built from the rollup module graph, so it lists the packages whose code actually ended up
 in the bundle. That is different from what `npm sbom`, `cyclonedx-npm` or Syft produce for a PCI: those
@@ -97,16 +98,30 @@ It also records a SHA-512 hash of the built bundle. A customer who integrates yo
 manufacturer of the complete product and has to do due diligence on integrated third party components;
 the hash lets them verify that the SBOM belongs to the bundle they received.
 
-The Cyber Resilience Act asks for an SBOM as part of the technical documentation, not as something you
-deliver with the product, so it is not put inside the package by default. Add `--include-sbom` if a
-customer wants it in the package anyway:
+The SBOM ships inside the package because a file next to the zip does not survive an import into an
+authoring system, and that system is exactly the party that needs it: it is the manufacturer of the
+complete product and has to document the components it integrates. The Cyber Resilience Act does not
+require in band delivery, so `--no-include-sbom` (or `config.tspci.sbom.includeInPackage: false`) keeps
+it out of the package while still writing it to `dist` and next to the package:
 
 ```sh
-  tspci --target qti3 --include-sbom
+  tspci --target qti3 --no-include-sbom
 ```
 
-Generating the SBOM needs no flag, it happens on every production build. Use `--no-sbom` to skip it for
-a single build, or `config.tspci.sbom.enabled: false` to switch it off for a project:
+Where it lands inside the package differs per target, always next to the bundle:
+
+| target | in the package |
+| --- | --- |
+| qti3 | `resources/pci/sbom.cdx.json`, listed as a file of the PCI resource in the manifest |
+| tao | `interaction/runtime/js/sbom.cdx.json` |
+| qbci | `ref/script/sbom.cdx.json` |
+
+For qti3 it is a `<file>` of the existing PCI resource rather than a resource of its own. QTI has no
+resource type for a bill of materials, and an unreferenced resource is what manifest driven tooling
+drops first.
+
+Generating the SBOM needs no flag either, it happens on every production build. Use `--no-sbom` to skip
+it for a single build, or `config.tspci.sbom.enabled: false` to switch it off for a project:
 
 ```sh
   tspci --target qti3 --no-sbom
@@ -165,7 +180,7 @@ All settings are optional and live in `config.tspci.sbom` in your `package.json`
 | `supportPeriodEnd` | - | Recorded as a property on the PCI component |
 | `externalReferences` | - | CycloneDX external references for the PCI, e.g. your disclosure policy |
 | `additionalComponents` | `[]` | Components the bundler cannot see, e.g. CDN or vendored code |
-| `includeInPackage` | `false` | Always include the SBOM in the exported package |
+| `includeInPackage` | `true` | Set to `false` to keep the SBOM out of the exported package |
 | `properties` | `[]` | Extra CycloneDX properties on the PCI component |
 | `warnings` | `true` | Set to `false` to silence the warnings about gaps |
 | `timestamp` | `false` | Include a build timestamp. Off by default so a rebuild of the same sources gives an identical document |
@@ -291,8 +306,8 @@ Available Commands
   --targetExt -tx Same as -target but reffering to a fully qualified package (not in @citolab)
   init            Init PCI development environment.
   add --target    Add specific implementation to the PCI.
-  --include-sbom  Include the generated SBOM in the exported package
-  --no-sbom       Do not generate an SBOM for this build
+  --no-include-sbom  Keep the SBOM out of the exported package (included by default)
+  --no-sbom          Do not generate an SBOM for this build
 
 Examples package.json scripts
 	$ "dev": "tspci --dev",

package/release-notes.md

@@ -1,3 +1,14 @@
+# 2.12.0
+
+- the SBOM is now included in the exported package by default, next to the bundle it describes: `resources/pci/sbom.cdx.json` (qti3), `interaction/runtime/js/sbom.cdx.json` (tao), `ref/script/sbom.cdx.json` (qbci)
+- a copy is still written next to the package as `<package-name>.sbom.cdx.json` for your own technical documentation
+- `--no-include-sbom` (or `config.tspci.sbom.includeInPackage: false`) keeps it out of the package, `--no-sbom` still skips it altogether
+- replaces `--include-sbom` from 2.11.0, which is now the default. The flag is still accepted and does nothing
+
+  A file next to the zip does not survive an import into an authoring system, and that system is exactly
+  the party that needs the SBOM: it is the manufacturer of the complete product and has to document the
+  components it integrates.
+
 # 2.11.0
 
 - every production build writes a CycloneDX 1.6 SBOM of the bundle to `dist/sbom.cdx.json`, and a package export copies it next to the package as `<package-name>.sbom.cdx.json`

package/src/cli.js

@@ -270,7 +270,7 @@ const run = async () => {
     console.log(`•\t${chalk.blueBright("--watch")} watch the files`);
     console.log(`•\t${chalk.blueBright("--target")} build a prod item and bundle for platform`);
     console.log(
-      `•\t${chalk.blueBright("--include-sbom")} include the generated sbom (dist/sbom.cdx.json) in the package itself`
+      `•\t${chalk.blueBright("--no-include-sbom")} keep the generated sbom out of the exported package (it is included by default)`
     );
     console.log(`•\t${chalk.blueBright("--no-sbom")} do not generate an sbom for this build`);
     console.log("\n");