Skip to content

Conversation

@Jacksondr5
Copy link

Moves the types packages in db-client to devDependencies.

Apologies, I'm not familiar with yarn. When I ran yarn install after making the change, 2 large plug'n'play files got generated that weren't known to git. I didn't include those changes, but I'm also not sure if some kind of lockfile was supposed to generate. Please let me know if I need to do something different here.

The reasoning behind this change is that types packages shouldn't be included in the bundle brought down to repos that install this package. After turning on pnpm's trustPolicy in my repo where we use this package, I got an error about @types/node from this package:
image

If the types packages get moved to devDependencies, pnpm won't attempt to install them in my repo and this issue goes away.

@CLAassistant
Copy link

CLAassistant commented Nov 25, 2025

CLA assistant check
All committers have signed the CLA.

@alexeyzimarev
Copy link
Member

/review

@qodo-code-review
Copy link

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 1 🔵⚪⚪⚪⚪
🧪 No relevant tests
🔒 No security concerns identified
⚡ Recommended focus areas for review

Type Availability

Moving type packages to devDependencies is correct for consumers, but ensure the package’s build or type-check steps don’t require these at runtime in environments that only install production dependencies (e.g., during prepublish or postinstall scripts). Verify CI and publish pipeline install dev deps before generating artifacts.

"devDependencies": {
  "@types/debug": "^4.1.12",
  "@types/google-protobuf": "^3.15.12",
  "@types/node": "^22.10.2",
  "@types/semver": "^7.7.0",
  "@types/uuid": "^10.0.0",
  "grpc-tools": "^1.12.4",
  "grpc_tools_node_protoc_ts": "^5.3.3",
Semver Compatibility

The version of @types/node (^22.10.2) should align with the declared Node engine (>=20). Confirm no TypeScript lib settings rely on Node 22-specific types that could break Node 20 targets during development.

"@types/debug": "^4.1.12",
"@types/google-protobuf": "^3.15.12",
"@types/node": "^22.10.2",
"@types/semver": "^7.7.0",

@George-Payne
Copy link
Member

George-Payne commented Nov 25, 2025

Hi Jackson,

The types are included in dependencies as they are dependencies of our typescript types, moving them to devDependencies will break the types for typescript users (who don't also happen to depend on the same types).

This is typescript's recommended approach for packages that bundle types:

https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html#packaging-dependent-declarations
https://www.typescriptlang.org/docs/handbook/declaration-files/publishing.html#dependencies

image image

The "trust downgrade" problem with undici is discussed here:
nodejs/undici#4666

It doesn't look like they want to put out a newer version of 6.* with provenance, but you can probably work around it by using pnpm's overrides.

If you're using typescript and a version of @node/types yourself, you could override the @types/node version to your own version:

package.json

{
 // ...
  "pnpm": {
    "overrides": {
      "@kurrent/kurrentdb-client>@types/node": "$@types/node"
    }
  }
}

Which should work fine with our package (I've not tested it), and ensure pnpm only installs types for the version of node you actually use, which hopefully depends on a version of undici-types that is published with provenance.

If you're not using typescript at all, you could also tell pnpm not to install node's types from @kurrent/kurrentdb-client:

package.json

{
 // ...
  "pnpm": {
    "overrides": {
      "@kurrent/kurrentdb-client>@types/node": "-"
    }
  }
}

or from any package:

package.json

{
 // ...
  "pnpm": {
    "overrides": {
      "@types/node": "-"
    }
  }
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants