fix(table-core): guard process.env.NODE_ENV checks for bundler-less environments

[koreahghg]

🎯 Changes

Fixes #6078.

table-core's ~14 dev-only debug/validation checks read process.env.NODE_ENV directly. That raw read survives unguarded into the published ESM build (unbundle: true, no define in tsdown.config.ts), so any environment with no process global — vanilla JS loaded via an import map, or any other bundler-less/non-Node setup — throws ReferenceError: process is not defined the moment one of these checks runs (e.g. simply constructing a table with debugTable: true).

Added a single isDevelopmentEnv() helper in utils.ts that checks typeof process !== 'undefined' before reading process.env.NODE_ENV, and routed all 14 call sites through it. Behavior is otherwise unchanged — still === 'development', not flipped to !== 'production' (that was the debated part of the related draft PR #6445, which is why it's stuck; this PR intentionally only fixes the crash and leaves that semantic question alone).

Verified the fix actually reaches the published artifact: after building, the only process.env reference left in dist/utils.js is the guarded one inside isDevelopmentEnv().

✅ Checklist

• I have followed the steps in the Contributing guide.
• I have tested this code locally with pnpm run test:pr (ran the equivalent steps directly: vitest run for @tanstack/table-core — 1275/1275 passing, including new regression tests — plus tsc --noEmit, eslint, and a tsdown build; the full nx affected pipeline timed out locally on an unrelated test:sherif/test:knip pass over the whole workspace).

🚀 Release Impact

• This change affects published code, and I have generated a changeset.
• This change is docs/CI/dev-only (no release).

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: bf13db6e-552a-4a36-996a-dc754fec8a66

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[MILLERMARRU]

Checked the full diff, all 14 raw process.env.NODE_ENV reads got routed through isDevelopmentEnv() (grepped for leftover unguarded reads across the changed files, none left). The typeof process !== 'undefined' guard is the right fix for the actual bug (#6078), a ReferenceError on process itself, not a value-checking issue.

Agreed with keeping this scoped to just the crash. The development vs !== production semantics debated on #6445 is a separate, more contentious question (default-on vs default-off checks in unconfigured production builds) and bundling it here would've blocked a straightforward crash fix behind an unrelated design decision. Good call leaving that for #6445 to resolve on its own.

One thing I'd double check before merge: isDevelopmentEnv() itself needs to live somewhere that doesn't get tree-shaken oddly given it's now imported into ~10 different feature files, worth confirming the dist/utils.js check you did in the description also holds for the tree-shaken per-feature entry points if table-core publishes those separately, not just the main bundle.

[koreahghg]

Good catch! checked this by actually building the branch (tsdown) and inspecting dist/.

Only dist/utils.js contains any process.env reference across the whole build, and it's the guarded isDevelopmentEnv(). Traced the import graph for all 6 published entry points:

• index.js, static-functions.js, experimental-worker-plugin.js → do reach utils.js (guarded)
• flex-render.js, reactivity.js, store-reactivity-bindings.js → don't reference utils.js at all (unrelated to the dev-check code, tree-shaken out)

So the guard holds across every per-feature entry point that actually uses it — no unguarded reads leak into any of the published bundles.