Review finding from @karthik-indla on this PR. src/mem0-utils.ts carried PROVIDER_VERSION = "3.0.2" as a literal. It matches package.json today and misreports the client version from the next release bump onwards, which is the one thing X-Mem0-Client exists to carry. Every other client in the repo injects at build: mem0-ts via __MEM0_SDK_VERSION__, the Python side via importlib.metadata, the CLIs via __CLI_VERSION__. tsup now defines __MEM0_PROVIDER_VERSION__ from package.json, and the source falls back to "dev" only when run unbundled, such as in tests. Verified in the built bundle: PROVIDER_VERSION resolves to "3.0.2" and no placeholder survives. resolveJsonModule is enabled alongside it, matching mem0-ts, because tsc --noEmit covers tsup.config.ts and the package.json import fails without it. Type check clean, build clean. The jest suite's failure is pre-existing and unrelated: it requires a live MEM0_API_KEY, confirmed by running it on a stashed tree. Python side 311 passed, 8 skipped; pi-agent 94 passed. Claude-Session: https://claude.ai/code/session_01C7tEmH86HAr7GoAAKCEHZb
17 lines
515 B
TypeScript
17 lines
515 B
TypeScript
import { defineConfig } from 'tsup'
|
|
import pkg from './package.json'
|
|
|
|
export default defineConfig([
|
|
{
|
|
dts: true,
|
|
entry: ['src/index.ts'],
|
|
format: ['cjs', 'esm'],
|
|
sourcemap: true,
|
|
// Injected rather than written in the source. A hardcoded literal matches
|
|
// package.json on the day it is written and misreports the client version
|
|
// from the next release bump onwards. Same mechanism as mem0-ts.
|
|
define: {
|
|
__MEM0_PROVIDER_VERSION__: JSON.stringify(pkg.version),
|
|
},
|
|
},
|
|
]) |