RI-8216 [PoC] Shared UI/API code location (ri-shared)

[VaskoAtanasovRedis]

What

PoC for a single in-repo location for code shared between the UI and the API, prompted by the review discussion on #6053. Extracts the BigInt-as-string array-index helper (previously two mirrored modules) as the example — everything else is out of scope.

• Shared source lives at redisinsight/api/src/ri-shared/ — inside the api compile root on purpose: nest build's tsc rootDir inference restructures dist/ when sources live outside api/src, breaking node dist/src/main and the desktop's hardcoded ../api/dist/src. Inside it, the module ships like any other api file → zero new packaging surface.
• UI consumes it via a bare riShared/* alias (same pattern as apiClient), wired in ui tsconfig, Vite, root jest, Storybook, and the desktop type-check tsconfig.
• The mirrors and their duplicate specs are deleted; both sides' barrels re-export from the shared module, so no consumer changed. Gatekeeping rules ("what belongs here": cross-boundary contracts + dependency-free utils, es2019-compatible, no framework imports) live in ri-shared/README.md.
• Rejected alternative: an in-repo file: package — yarn-classic copies at install (stale during dev) and churns three lockfiles under the CI drift gate.

Testing

• API: yarn --cwd redisinsight/api test --testPathPattern "array-index" — 40 tests (shared module spec + decorator)
• UI consumers via barrels: existing suites green; real vite build (production) resolves the alias
• Real nest build: shared module emits inside dist/src/, imports rewritten to relative requires, compiled barrel smoke-tested under plain node
• yarn lint + yarn type-check green across all projects
• This PR exists to verify packaging: manual GHA desktop builds (win/mac/linux distros) + install checks — the one surface not verifiable locally

---

References: #RI-8216

🤖 Generated with Claude Code

[jit-ci]

🛡️ Jit Security Scan Results

✅ No security findings were detected in this PR

---

^{Security scan by Jit}

[github-actions]

Code Coverage - Backend unit tests

St.❔	Category	Percentage	Covered / Total
🟢	Statements	92.73%	15742/16976
🟡	Branches	74.72%	4960/6638
🟢	Functions	86.89%	2453/2823
🟢	Lines	92.57%	15043/16251

Test suite run success

3494 tests passing in 311 suites.

Report generated by 🧪jest coverage report action from b23fa6d

[github-actions]

Code Coverage - Integration Tests

Status	Category	Percentage	Covered / Total
🟡	Statements	78.75%	17520/22245
🟡	Branches	61.52%	8061/13103
🟡	Functions	66.45%	2397/3607
🟡	Lines	78.3%	16468/21031

[github-actions]

Code Coverage - Frontend unit tests

St.❔	Category	Percentage	Covered / Total
🟢	Statements	83.18%	25284/30397
🟡	Branches	68.46%	10667/15582
🟡	Functions	78.3%	6792/8674
🟢	Lines	83.64%	24681/29509

Test suite run success

7150 tests passing in 814 suites.

Report generated by 🧪jest coverage report action from b23fa6d

[KrumTy]

a shared package/dir should not be inside api folder, it would be in redisinsight/ri-shared

[VaskoAtanasovRedis]

Good instinct, and I went down that path — but there's a build constraint that makes a true top-level redisinsight/ri-shared much more involved than a relocation, so I've kept it at api/src/ri-shared for now. Reasoning:

The API actually consumes this util (the array-index validator imports it), so it has to be compiled into the api's dist. The api's tsconfig has no explicit rootDir, so tsc infers it from the common ancestor of all compiled files — today that's src, giving us dist/src/.... The moment a file from ../ri-shared enters the compile, the common ancestor becomes redisinsight/ and tsc emits dist/api/src/main.js + dist/ri-shared/... instead.

That breaks two things that hard-depend on the current layout:

• node dist/src/main (the start:prod / start:stage boot path)
• the desktop app's hard-coded api/dist/src/... imports — desktop/src/lib/server/server.ts does import server from '../../../../api/dist/src/main', plus the azure / cloud-auth / window-auth modules

api-client gets to live top-level only because it's UI-consumed and never goes through nest build — ri-shared can't follow that pattern since the API compiles it.

To put it genuinely top-level we'd need to make ri-shared its own independently-built TS unit (project reference + own dist) and wire it into both api runtime resolution and desktop packaging — a real chunk of work + new CI surface for what's currently one small shared util. The api/src/ri-shared folder keeps the "shared, dependency-free, both-sides" boundary explicit (see its README) with zero packaging risk. If we accumulate enough shared code to justify the standalone package later, happy to revisit — flag it if you'd rather take that on now.