Mark @sap/cds-dk peer dependency as optional #155

@cap-js/notifications@1.1.1 declares @sap/cds-dk as a required peer dependency:

"peerDependencies": {
  "@sap/cds": ">=8.0",
  "@sap/cds-dk": ">=8.0"
}

With npm 7+, this installs @sap/cds-dk and its complete dependency tree into the production dependency graph of every consuming application.

However, @sap/cds-dk appears to be needed only for the CAP build integration:

cds.build?.register?.("notifications", require("./lib/build"))

lib/build.js extends cds.build.Plugin, and it is only loaded when the build API is available. Neither the runtime services under srv/ nor the notification delivery code import @sap/cds-dk directly.

This makes @sap/cds-dk a build-tool prerequisite rather than a runtime dependency of applications that use the notification service.

Impact

In our CAP application, the automatically installed @sap/cds-dk@8.9.19 dependency tree brings in packages that our production security scanner reports, including vulnerable versions of handlebars, @sap/cds-mtxs, proxy-addr, axios, ws and qs.

cds-dk releases use either an npm-shrinkwrap.json (8.x, 9.x) or bundled dependencies (10.x), so consuming applications cannot reliably fix these transitive findings with npm overrides.

A possible workaround we found is:

legacy-peer-deps=true

This stops the peer from being installed, but it changes peer dependency resolution for the entire project.

Proposal

Mark the peer dependency as optional:

"peerDependenciesMeta": {
  "@sap/cds-dk": {
    "optional": true
  }
}

Applications that use the build plugin would then provide @sap/cds-dk explicitly, for example as a devDependency, through a controlled CI build image, or with an explicitly versioned npx / npm exec command.

Runtime-only installations would no longer pull in the complete cds-dk build-tool dependency tree automatically.

The build integration keeps working whenever cds-dk is available, and cds-dk no longer ends up in the production dependency graph by default.