@effect/platform-node: root imports require redis even for non-Redis APIs

[corelix]

What version of Effect is running?

• effect: 4.0.0-rc.117
• @effect/platform-node: 4.0.0-rc.117
• Node.js: 26.9.0
• pnpm: 12.4.2

Both Effect packages match the current rc dist-tag at the time of reporting.

What steps can reproduce the bug?

Create an empty directory with the following files.

package.json:

{
  "private": true,
  "type": "module",
  "dependencies": {
    "effect": "4.0.0-rc.117",
    "@effect/platform-node": "4.0.0-rc.117"
  }
}

pnpm-workspace.yaml:

autoInstallPeers: false

Install dependencies and import the package:

pnpm install --ignore-scripts
node --input-type=module -e 'await import("@effect/platform-node")'

The import fails because redis is missing.

For comparison, both of these imports succeed in the same installation:

node --input-type=module -e 'await import("@effect/platform-node/NodeRuntime")'
node --input-type=module -e 'await import("@effect/platform-node/NodeHttpServer")'

Disabling automatic peer installation is intentional: it exposes whether applications that do not use Redis can consume the package without installing the Redis client.

What is the expected behavior?

Applications using only non-Redis APIs should ideally be able to consume @effect/platform-node without installing the Redis client, including through the root entry point.

If requiring Redis for all consumers is intentional, could this requirement and the recommended import strategy be documented?

What do you see instead?

The root import fails with:

ERR_MODULE_NOT_FOUND: Cannot find package 'redis' imported from .../@effect/platform-node/dist/NodeRedis.js

The root entry point re-exports NodeRedis, whose module imports redis at the top level. This loads the Redis dependency even when the application does not use Redis APIs.

Additional information

I recognize that redis is currently a required peer dependency, so this reproduction deliberately omits a declared requirement. The concern is whether that requirement needs to apply to non-Redis consumers.

Automatic peer installation satisfies the requirement but installs the Redis client for those consumers as well. Direct subpath imports avoid the runtime failure, although the mandatory peer requirement remains.

Marking the peer optional alone would not resolve the root-import failure; the eager import would also need to be addressed.

Related work:

• Migrate NodeRedis from ioredis to redis (node-redis) #7221 migrated NodeRedis from ioredis to node-redis.
• fix(platform-bun): load Bun's RedisClient lazily so the barrel imports under Node #7564 addressed a similar eager Redis import in the @effect/platform-bun root entry point.

Would you consider isolating Redis loading to Redis-specific usage and making the peer optional, or is the current package-wide requirement intentional?

[tim-smart]

redis is a required peerDependency so yes it is intentional. If you want to avoid importing NodeRedis you can avoid the barrel import.

[tenkoverse]

redis is a required peerDependency so yes it is intentional. If you want to avoid importing NodeRedis you can avoid the barrel import.

I’m using @effect/platform-node to run Effect on Node ... not to opt into Redis. Choosing a runtime shouldn’t force me to install an unrelated database client that I don't use or need.

Avoiding the barrel import only avoids loading Redis. With autoInstallPeers: false and strictPeerDependencies: true, pnpm still rejects installation without it. Enabling automatic peer installation just installs the client I don’t need.

I’m questioning that dependency boundary. Redis integration should be something consumers explicitly choose, not a requirement imposed on every consumer of @effect/platform-node.

[tim-smart]

Node/bun/deno each have different recommended clients which is why it is part of the platform services. We will not be adding separate packages just for redis integration.

[tenkoverse]

different recommended clients .. We will not be adding separate packages just for redis integration.

you already do this for other database integrations... node and bun already have separately installable SQLite adapters. “different recommended clients” doesn’t explain why a redis client has to be mandatory baggage for my application that never uses it.