fix(table-core): Avoid process not defined in environments not setting a process variable

[timrittgers]

When running the library in an environment that is not setting the process variable, the library throws a not defined error and breaks the render. This change checks to see if the variable exists before attempting to read it to avoid this.

[KevinVandy]

What environments do that?

[timrittgers]

What environments do that?

I have a situation where we are bundling Tanstack into a library component, then distributing the component as a standalone package that can be loaded directly in an html page. In this scenario, there is no process variable defined and the tanstack library fails.

[KevinVandy]

Are you sure that you're not accidentally importing from src instead of the proper build output?

Also, maybe try importing from the umd output, which does not have any process.env in its output

[timrittgers]

Are you sure that you're not accidentally importing from src instead of the proper build output?

Also, maybe try importing from the umd output, which does not have any process.env in its output

I'm importing the Tanstack library into my project's component like this:

import {
  Cell,
  ColumnDef,
  ColumnSort,
  createColumnHelper,
  getCoreRowModel,
  getFilteredRowModel,
  getPaginationRowModel,
  getSortedRowModel,
  Header,
  PaginationState,
  RowModel,
  Table,
  TableOptions,
  TableState,
} from '@tanstack/table-core';

There wouldn't be a way to just import the pieces I need using the umd, would there?

I'm also curious what the harm would be in detecting the process variable in the library before calling it?

[KevinVandy]

I'm also curious what the harm would be in detecting the process variable in the library before calling it?

I have just never seen any other NPM library ever have to do this, so I think there should be a better way.

[lschierer]

I hit this trying to use tanstack table in Greenwood

[thescientist13]

Hey, stumbled across this with @lschierer and did a little digging and have some observations to share if it helps 👋

What environments do that?

browser / client environments, no bundle development workflows, etc.

Also, maybe try importing from the umd output, which does not have any process.env in its output

Tools following NodeJS exports spec looking for ESM files would look to the import conditions, assuming "pure" ESM. In the absence of an exports field, they can optionally look for the module field.

In package.json both the module field and the import sub condition in the exports map field both point to built files that still include process.

• module - https://unpkg.com/browse/@tanstack/[email protected]/build/lib/index.esm.js
• import - https://unpkg.com/browse/@tanstack/[email protected]/build/lib/index.mjs

(Curious, is there any reason module and import would point to different file outputs? I think they could / should probably be the same for ESM based content)

I have just never seen any other NPM library ever have to do this, so I think there should be a better way.

It's worth noting that the reason most NPM libraries don't guard against this is because most people "erase" it away through their build tools.

For instance, you can see that happening in this project in its examples and own build step

• table/examples/lit/basic/vite.config.js

  Line 11 in 827b098

  'process.env.NODE_ENV': JSON.stringify('development'),

• table/scripts/getRollupConfig.js

  Line 18 in 827b098

  'process.env.NODE_ENV': `"${type}"`,

• table/examples/react/query-router-search-params/vite.config.js

  Line 13 in 827b098

  'process.env.NODE_ENV': JSON.stringify('development'),

• table/examples/react/kitchen-sink/vite.config.js

  Line 12 in 827b098

  'process.env.NODE_ENV': JSON.stringify('development'),

• etc

---

An alternative to guarding would be that for client side / browser / UI libraries don't include any non web standard (e.g. NodeJS APIs)

Not the biggest deal, but hopefully it's helpful information either way. 👍