Published types in @deephaven npm packages are not NodeNext compatible #2273
Description
When deploying @deephaven npm packages, we build the packages by running npm run build. This:
- Builds the types via the tsc compiler (via the "types" script)
- Builds the source code via Babel (via the "build:packages" script)
ESM modules require imports to include the file extension. The Babel compilation seems to produce proper ESM compatible imports by adding the extensions to imports, while the types build does not. This is because TypeScript will not automatically add file extensions, it leaves it up to the author to add the extensions. This causes trouble if a consumer configured for NodeNext attempts to import types.
As an example, when configuring a project as "module": "NodeNext" this fails to find the type:
// It seems the compiler will not find the type that exists deeper than the `index.d.ts` (presumably) due to missing
// file extensions on the imports
import type { Brand } from '@deephaven/utils';This works:
import type { Brand } from '@deephaven/utils/dist/TypeUtils.d.ts';Options I'm aware of that would fix this are:
- Re-export explicitly named types instead of
export type *(not sure why this actually works and doesn't really seem a proper fix) - Convert imports in the source code to include the
.jsextension. This would be a large refactor to fix the entire codebase. Could be worth targetting specific modules. Also could be worth automating in 1 pass at some point as this seems to be the "proper" format to use. Update imports to use explicit file extensions #223 - Figure out if there are any transpiler / compiler options that would add the extensions as part of the build
Lastly, it seems like some scenarios work as-is, so "not ESM compatible" may be a bit too strong of a statement, but it seems we should investigate what the "proper" format should be here for broader compatibility.