OCP-1512 remove node fetch

[khaled-maruf]

What

OCP-1512: migrate out of node-fetch

• use native fetch api, cleaner and needs one less dependency

OCP-1512: use latest eslint-config-presets

• this allows removing a lot of un-needed dependencies now

OCP-1512: remove warnings for typesript compilation

• without the new config isolatedModules the typescript compilation would show warnings like below

ts-jest[ts-compiler] (WARN) Using hybrid module kind (Node16/18/Next) is only supported in "isolatedModules: true". Please set "isolatedModules: true" in your tsconfig.json.
ts-jest[ts-compiler] (WARN) Using hybrid module kind (Node16/18/Next) is only supported in "isolatedModules: true". Please set "isolatedModules: true" in your tsconfig.json.

• with the configs, things still work. From ClaudeCode,

  1. JavaScript Output (Runtime)

  The compiled index.js file shows:
  exports.configOrDefault = void 0; // Only exports the runtime value

  • Types are completely erased at runtime (as always with TypeScript)
  • The JS output is identical whether you use export or export type
  2. TypeScript Declaration File (.d.ts)

  The index.d.ts file shows:
  export { configOrDefault } from './configure';
  export type { Config } from './configure';

  3. Consumer Import Compatibility

  All these import patterns will continue to work:

  // Mixed import (most common)
  import { Config, configOrDefault } from '@zaiusinc/node-sdk';

  // Explicit type import
  import type { Config } from '@zaiusinc/node-sdk';

  // Inline type import (newer syntax)
  import { type Config, configOrDefault } from '@zaiusinc/node-sdk';

  TypeScript automatically understands that Config is a type regardless of how it's exported.

  4. For JavaScript Consumers
  • No impact - they don't use types anyway
  • The runtime code is unchanged

OCP-1512: move from jest to vitest

• vitest is faster, this makes the tests run ~2x faster than jest.

Info

• Please check the changes commit by commit, the Jest -> vitest conversion has most of the file changes FYI, so that you don't get daunted by the number of file changes.

[pawelziebaopti]

looks good to me in general!

the only question is about bumping major version - what's the plan for using this version? are we going to support both 2.x and 3.x for node22 runtime?

[pawelziebaopti]

another question is about bumping min node version for the lib - is it required by the change (e.g. a dependency doesn't support node18 any more) or it's just for auto-detection of node version by github workflow?

[khaled-maruf]

looks good to me in general!

the only question is about bumping major version - what's the plan for using this version? are we going to support both 2.x and 3.x for node22 runtime?

The reason I bumped it because of the Headers type that now has been moved from node-fetch to native node, users upgrading their app to this version will start getting ts compilation errors because the types are not coming from the same source.

I guess we'll have to have separate entries for version 2 and 3 in zap-build for node 22, which should work, in that case we can continue supporting version 2 as well, but probably we need to figure out from when should we start deprecating it.

[khaled-maruf]

another question is about bumping min node version for the lib - is it required by the change (e.g. a dependency doesn't support node18 any more) or it's just for auto-detection of node version by github workflow?

I did it for the node version checker on the other PR. Also, it made sense to bump this as well with the Major version bump I did. I guess it's fine? If not I can revert this.

[pawelziebaopti]

ok, makes sense. approved

[khaled-maruf]

@pawelziebaopti ,
Removed the fixup commit, need another approval now...