feat(event-client): strip the root EventClient export from production by default (#471)

* feat(event-client): add shared types module, /production entry, and package wiring

* feat(event-client): add standalone no-op client and share event types

* feat(event-client): no-op the root export outside development

* docs(event-client): document dev-only root export and /production subpath

* chore(event-client): add changeset for production stripping

* test(event-client): guard no-op/real public-surface parity and cover the dev resolver branch

* docs(event-client): clarify unset NODE_ENV behavior and fix stale stripping guidance

* ci: apply automated fixes

---------

Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>

Author: AlemTuzlak

.changeset/event-client-production-stripping.md

@@ -0,0 +1,12 @@
+---
+'@tanstack/devtools-event-client': minor
+---
+
+The root export of `@tanstack/devtools-event-client` now resolves to a no-op
+outside development (`process.env.NODE_ENV !== 'development'`), so the real
+`EventClient` is tree-shaken out of production bundles by default.
+
+If you want devtools events to keep working in production, import the real
+client from the new `@tanstack/devtools-event-client/production` subpath, which
+always ships the real implementation. The public API is identical between the
+two imports.

docs/building-custom-plugins.md

@@ -209,3 +209,27 @@ For usage details, see the [Using devtools-utils](./devtools-utils) guide.
 Once your plugin is working, you can share it with the community by publishing it to npm and submitting it to the TanStack Devtools Marketplace. The marketplace is a registry of third-party plugins that users can discover and install directly from the devtools UI.
 
 For submission instructions and the registry format, see [Third-party Plugins](./third-party-plugins).
+
+## Production builds
+
+By default the **root import** of `@tanstack/devtools-event-client` no-ops
+outside development. When your bundler sets `process.env.NODE_ENV` to anything
+other than `'development'`, the real client is replaced by a no-op and
+tree-shaken out of your production bundle:
+
+```ts
+// dev: real client — production: no-op (tree-shaken away)
+import { EventClient } from '@tanstack/devtools-event-client'
+```
+
+If you are an open-source author who deliberately wants devtools events in
+production, import the real client from the `/production` subpath instead. It is
+never stripped:
+
+```ts
+// always the real client, in every environment
+import { EventClient } from '@tanstack/devtools-event-client/production'
+```
+
+The public API is identical between the two imports — only the production
+runtime behavior differs.

docs/framework/angular/guides/custom-plugins.md

@@ -215,3 +215,27 @@ Heres an example of both:
 
 [tanstack-devtools:custom-devtools-plugin] Registered event to bus custom-devtools:counter-state
 ```
+
+## Production builds
+
+By default the **root import** of `@tanstack/devtools-event-client` no-ops
+outside development. When your bundler sets `process.env.NODE_ENV` to anything
+other than `'development'`, the real client is replaced by a no-op and
+tree-shaken out of your production bundle:
+
+```ts
+// dev: real client — production: no-op (tree-shaken away)
+import { EventClient } from '@tanstack/devtools-event-client'
+```
+
+If you are an open-source author who deliberately wants devtools events in
+production, import the real client from the `/production` subpath instead. It is
+never stripped:
+
+```ts
+// always the real client, in every environment
+import { EventClient } from '@tanstack/devtools-event-client/production'
+```
+
+The public API is identical between the two imports — only the production
+runtime behavior differs.

docs/framework/preact/guides/custom-plugins.md

@@ -202,3 +202,27 @@ Heres an example of both:
 
 🌴 [tanstack-devtools:custom-devtools-plugin] Registered event to bus custom-devtools:counter-state
 ```
+
+## Production builds
+
+By default the **root import** of `@tanstack/devtools-event-client` no-ops
+outside development. When your bundler sets `process.env.NODE_ENV` to anything
+other than `'development'`, the real client is replaced by a no-op and
+tree-shaken out of your production bundle:
+
+```ts
+// dev: real client — production: no-op (tree-shaken away)
+import { EventClient } from '@tanstack/devtools-event-client'
+```
+
+If you are an open-source author who deliberately wants devtools events in
+production, import the real client from the `/production` subpath instead. It is
+never stripped:
+
+```ts
+// always the real client, in every environment
+import { EventClient } from '@tanstack/devtools-event-client/production'
+```
+
+The public API is identical between the two imports — only the production
+runtime behavior differs.

docs/framework/react/guides/custom-plugins.md

@@ -199,3 +199,27 @@ Heres an example of both:
 
 🌴 [tanstack-devtools:custom-devtools-plugin] Registered event to bus custom-devtools:counter-state
 ```
+
+## Production builds
+
+By default the **root import** of `@tanstack/devtools-event-client` no-ops
+outside development. When your bundler sets `process.env.NODE_ENV` to anything
+other than `'development'`, the real client is replaced by a no-op and
+tree-shaken out of your production bundle:
+
+```ts
+// dev: real client — production: no-op (tree-shaken away)
+import { EventClient } from '@tanstack/devtools-event-client'
+```
+
+If you are an open-source author who deliberately wants devtools events in
+production, import the real client from the `/production` subpath instead. It is
+never stripped:
+
+```ts
+// always the real client, in every environment
+import { EventClient } from '@tanstack/devtools-event-client/production'
+```
+
+The public API is identical between the two imports — only the production
+runtime behavior differs.

docs/framework/solid/guides/custom-plugins.md

@@ -195,3 +195,27 @@ Heres an example of both:
 
 [tanstack-devtools:custom-devtools-plugin] Registered event to bus custom-devtools:counter-state
 ```
+
+## Production builds
+
+By default the **root import** of `@tanstack/devtools-event-client` no-ops
+outside development. When your bundler sets `process.env.NODE_ENV` to anything
+other than `'development'`, the real client is replaced by a no-op and
+tree-shaken out of your production bundle:
+
+```ts
+// dev: real client — production: no-op (tree-shaken away)
+import { EventClient } from '@tanstack/devtools-event-client'
+```
+
+If you are an open-source author who deliberately wants devtools events in
+production, import the real client from the `/production` subpath instead. It is
+never stripped:
+
+```ts
+// always the real client, in every environment
+import { EventClient } from '@tanstack/devtools-event-client/production'
+```
+
+The public API is identical between the two imports — only the production
+runtime behavior differs.

docs/framework/vue/guides/custom-plugins.md

@@ -202,3 +202,27 @@ Heres an example of both:
 
 [tanstack-devtools:custom-devtools-plugin] Registered event to bus custom-devtools:counter-state
 ```
+
+## Production builds
+
+By default the **root import** of `@tanstack/devtools-event-client` no-ops
+outside development. When your bundler sets `process.env.NODE_ENV` to anything
+other than `'development'`, the real client is replaced by a no-op and
+tree-shaken out of your production bundle:
+
+```ts
+// dev: real client — production: no-op (tree-shaken away)
+import { EventClient } from '@tanstack/devtools-event-client'
+```
+
+If you are an open-source author who deliberately wants devtools events in
+production, import the real client from the `/production` subpath instead. It is
+never stripped:
+
+```ts
+// always the real client, in every environment
+import { EventClient } from '@tanstack/devtools-event-client/production'
+```
+
+The public API is identical between the two imports — only the production
+runtime behavior differs.

docs/production.md

@@ -57,6 +57,32 @@ function App() {
 }
 ```
 
+## Event client in production
+
+By default the **root import** of `@tanstack/devtools-event-client` no-ops
+outside development. When your bundler sets `process.env.NODE_ENV` to anything
+other than `'development'`, the real client is replaced by a no-op and
+tree-shaken out of your production bundle:
+
+```ts
+// dev: real client — production: no-op (tree-shaken away)
+import { EventClient } from '@tanstack/devtools-event-client'
+```
+
+If you are an open-source author who deliberately wants devtools events in
+production, import the real client from the `/production` subpath instead. It is
+never stripped:
+
+```ts
+// always the real client, in every environment
+import { EventClient } from '@tanstack/devtools-event-client/production'
+```
+
+The public API is identical between the two imports — only the production
+runtime behavior differs.
+
+This is independent of the Vite plugin's `removeDevtoolsOnBuild` option — the event client strips itself based on `NODE_ENV`, whether or not you use the Vite plugin.
+
 ## Where to install the Devtools
 
 If you are using the devtools in development only, you can install them as a development dependency and only import them in development builds. This is the default recommended way to use the devtools.

packages/event-bus-client/README.md

@@ -37,3 +37,29 @@ plugin.on('b', (e) => {
 The `EventClient` class is a base class for creating plugins that can subscribe to events in the TanStack Devtools event bus. It allows you to define a set of events and their corresponding data schemas using a standard-schema based schemas.
 
 It will work on both the client/server side and all you have to worry about is emitting/listening to events.
+
+## Production builds
+
+By default the **root import** of `@tanstack/devtools-event-client` no-ops
+outside development. When your bundler sets `process.env.NODE_ENV` to anything
+other than `'development'`, the real client is replaced by a no-op and
+tree-shaken out of your production bundle:
+
+```ts
+// dev: real client — production: no-op (tree-shaken away)
+import { EventClient } from '@tanstack/devtools-event-client'
+```
+
+If you are an open-source author who deliberately wants devtools events in
+production, import the real client from the `/production` subpath instead. It is
+never stripped:
+
+```ts
+// always the real client, in every environment
+import { EventClient } from '@tanstack/devtools-event-client/production'
+```
+
+The public API is identical between the two imports — only the production
+runtime behavior differs.
+
+"Outside development" includes when `NODE_ENV` is unset — common in plain Node scripts, some SSR dev servers, and test runners — so the root import resolves to the no-op there too. Set `NODE_ENV=development`, or use the `/production` subpath, to get the real client in those contexts.

packages/event-bus-client/package.json

@@ -35,6 +35,16 @@
         "default": "./dist/cjs/index.cjs"
       }
     },
+    "./production": {
+      "import": {
+        "types": "./dist/esm/production.d.ts",
+        "default": "./dist/esm/production.js"
+      },
+      "require": {
+        "types": "./dist/cjs/production.d.cts",
+        "default": "./dist/cjs/production.cjs"
+      }
+    },
     "./package.json": "./package.json"
   },
   "bin": {