Skip to content

Someli — Code Overlap Matrix

This is the source-cited inventory of where the same code lives in more than one repo. Read this before doing cross-repo work; a fix in one repo often needs to be propagated to the siblings (and sometimes you'll discover it was already fixed in one of them).

All paths are relative to someli-gh/.

1. The shared-skeleton pattern

someli-api, designer-api, and Someli-admin-api all use the same Express bootstrap skeleton. They were forked from someli-api at different times. The shape is:

<repo>/
├── conf.js                          # re-exports process.env
├── server.js                        # boots Express + Socket.IO + MySQL, then mounts routes/routes.js
├── modules/dbDriver/lib/mysql.js    # callback-based MySQL pool wrapper
├── actions/actions.js               # generic CRUD layer
├── routes/routes.js                 # one giant file registering hundreds of endpoints
├── helper/                          # flat folder of utility modules
└── job_*.js                         # standalone PM2-runnable scripts

(someli-dashboard-be is a trimmed version of this skeleton — same idea, but only the dashboard slice.)

The skeleton lives in three forks that have drifted independently. The table below quantifies the drift.

2. helper/ overlap — Someli-admin-api vs someli-api

Someli-admin-api/helper/ contains 10 files. All 10 share filenames with someli-api/helper/. Of those:

File diff line count (someli-api ↔ Someli-admin-api) Interpretation
ragProcess.js 0 identical — safe to treat as shared
revokeToken.js 0 identical
tokenGenerator.js 0 identical
webScraping.js 0 identical
stockImage.js 49 lightly forked
index.js 63 lightly forked (different re-exports)
basic.js 119 meaningfully diverged
constants.js 163 meaningfully diverged
aiLogics.js 396 heavily diverged — each repo has its own AI logic
helper.js 856 heavily diverged — likely contains the bulk of the per-product business logic

Source: diff <someli-api/helper/X> <Someli-admin-api/helper/X> | wc -l for each file in Someli-admin-api/helper/.

Action items implied by this table: - tokenGenerator.js, revokeToken.js, ragProcess.js, webScraping.js should be extracted to a shared npm package — they are byte-identical, and divergence is a real risk. - aiLogics.js and helper.js divergence is large enough that fixes need to be considered per-repo. Don't assume a fix in one applies to the other.

3. modules/dbDriver overlap

modules/dbDriver/lib/mysql.js exists in someli-api, designer-api, and Someli-admin-api. The files differ slightly between designer-api and someli-api. Treat as drifting copies.

4. actions/actions.js overlap

Both someli-api/actions/actions.js and designer-api/actions/actions.js provide the same generic CRUD methods (getAll, insertData, updateData, deleteData, fetchAll, customQuery). The designer-api copy is a slightly older fork. Sample diff at line ~285 shows the someli-api copy has been hardened to handle null data and recursive object stringification; the designer-api copy has not.

5. Background jobs — someli-api vs designer-api

designer-api has 57 job_*.js files; someli-api has 108. Zero file names overlap. Inspecting the files:

  • someli-api jobs target the runtime social-media pipeline: publishing (job_facebook_publish.js, job_instagram_publish.js, job_linkedin_publish.js, job_tiktok_content_publish.js), token refresh (job_refresh_fb_token.js), insight aggregation, post validation, paddle webhooks, etc.
  • designer-api jobs target the template / content library content factory: industry-specific generators (job_auto_garge_ceramic_coating.js, job_disability_insurance.js, job_It_cyber_security.js, job_uae_estate.js, …), schedulers (job_schedule_dynamic.js, job_schedule_organization.js), and template validators (job_check_color_with_json.js, job_check_temp_valid.js).

Despite no filename overlap, the internal boilerplate of every designer-api job is identical: dotenvnode-cronsync-mysql connect → cron.schedule(…) → handler that issues raw SELECT … LIMIT N queries and processes rows. This is the same pattern as the older someli-api jobs. There is room to extract a shared job-base module.

Implication: designer-api is best thought of as a second PM2 worker pool that shares a database with someli-api. The split between them is what kind of work, not what data.

6. Polotno editor fork — someli-platform/polotno-editor vs Someli-Designer/polotno-editor

Both customer FE and designer FE bundle their own React + MobX-State-Tree + Polotno editor. They started from the same source and diverged. Concrete differences (sample from diff -rq):

  • Renamed file: brandkitpanel.js (customer) vs brandkitPanel.js (designer) — same purpose, casing differs
  • Only in someli-platform/polotno-editor/: aiContent/, aiImage.js, common/, customTextSection/, favouritesPannel.js, helper/, ImageLibraryPanel.js
  • Only in Someli-Designer/polotno-editor/: alltemplatesPanel.js, CustomPageControls.js, CustomWorkspace.js, helper.js
  • Diverged: App.js, app.css, carousaltemplatesPanel.js, customUploads.js, icons.js, index.html

Both produce a polotno-bundle.js artifact at their repo root. The customer FE's bundle is 221 KB; the designer FE's is 50 KB (much smaller — the designer's editor is narrower in scope).

Implication: There is no "Polotno editor library" — there are two cousins. Treat each as its own codebase. If a Polotno bug is reported, fix it in the affected fork first; only port to the other if the bug clearly exists there too.

7. Dashboard analytics service — someli-api/dashboard/ vs someli-dashboard-be/

someli-dashboard-be/ is a near-copy of someli-api/dashboard/. Differences (diff -rq):

  • README.md — different (the standalone has its own dev README)
  • routes/index.js — differs
  • server.js — differs

The standalone repo also has its own mock/ directory used when NODE_ENV=development. The in-process copy in someli-api/dashboard/ does not have this mock layer.

Production runs the in-process copy (mounted into someli-api/server.js at /auth per someli-api/CLAUDE.md). The standalone is for local-dev / future-extraction.

8. someli-mono-repo and someli-project snapshots

These two repos are read-only aggregations of the canonical repos. They are kept in git, but they are not auto-synced from the canonical sources; each is the state of an ad-hoc copy at some past date.

Snapshot path Mirrors canonical Drift (file diffs) Snapshot date (last commit)
someli-mono-repo/backend/ someli-api/ 49 file diffs 2026-01-20
someli-mono-repo/frontend/ someli-platform/ 333 file diffs 2026-01-20
someli-project/backend/app-backend/ someli-api/ 49 file diffs (same as above) 2026-01-23
someli-project/frontend/app-frontend/ someli-platform/ 333 file diffs (same as above) 2026-01-23
someli-project/backend/admin-backend/ Someli-admin-api/ 0 — identical 2026-01-23
someli-project/frontend/admin-frontend/ admin_console_R/ 0 — identical 2026-01-23
someli-project/backend/designer-backend/ designer-api/ 6 file diffs (Dockerfile, nginx.conf, push.sh, deploy_image.py, .dockerignore, routes/routes.js) 2026-01-23
someli-project/frontend/designer-frontend/ Someli-Designer/ 14 file diffs (Dockerfile + 13 editor .vue pages) 2026-01-23

Source: diff -rq excluding node_modules, .git, .nuxt, dist, .yarn, lockfiles, doc/, CLAUDE.md, .env*, prebuilt polotno-bundle.*, temp_video_* directories.

Rule: never edit inside someli-mono-repo/ or someli-project/. If they need updating, regenerate from canonical.

9. Canonical-vs-cloned (within this audit's environment)

This audit was performed on a workspace where two copies of someli-api and someli-platform coexist:

  • /home/nino/src/someli/someli-api (canonical working copy)
  • /home/nino/src/someli/someli-gh/someli-api (newer clone)
  • /home/nino/src/someli/someli-platform (canonical working copy)
  • /home/nino/src/someli/someli-gh/someli-platform (newer clone)

The cloned someli-gh/someli-platform is identical to the canonical (same HEAD: 380b2144).

The cloned someli-gh/someli-api is 7 commits ahead of the canonical (d02e2141 vs 8825ecdd). The 7 commits are all small fixes:

d02e2141 Merge PR #1618 from new/axios_version_changes1
56e2fcd0 fix: update axios dependency version to 1.15.0
e4fa35db fix: update publish key retrieval to use configuration file
33940689 fix: correct uid extraction logic in PDF generation process
f2ad2f45 feat: refactor codeChild iteration to use for loop and add debug logging
80a90d67 fix: simplify image source assignment by removing unnecessary base64 conversion
a956405d feat: add support for retrieving images from the Image Library in PDF generation

Concrete file diffs in someli-api (cloned vs canonical, ignoring node_modules, .git, .nuxt, .yarn, lockfiles):

  • package.jsonaxios bumped from ^1.9.0 to ^1.15.0
  • job_carousel_pdf.js — 55 lines of diff (the PDF generation feature work above)
  • slack_notifications_post_disconnect.js — small refactor to read PUBLISH_KEY from ./conf instead of directly from process.env, plus a new console.log at startup
  • Only-in-canonical (working files that aren't in git): CLAUDE.md, doc/, .env, 1290183.png, img.jpg, routes/temp_video_* directories (Polotno scratch space), .yarnrc

See _meta/canonical-vs-cloned.md for the same comparison for someli-platform.

10. Summary — what to do when you find duplicated code

Pattern What to do
Identical file in two repos (e.g., tokenGenerator.js in someli-api/helper/ and Someli-admin-api/helper/) Treat as shared. Plan extraction to a small shared package. In the meantime, propagate fixes to both.
Lightly-forked file (e.g., stockImage.js) Read both before fixing. The intent is probably the same; double-apply if the fix is universal.
Heavily-forked file (e.g., helper.js, aiLogics.js) Do not assume parity. Fix only where the user-visible bug is. Note divergence in PR.
Same boilerplate, different content (e.g., job_*.js files) Leave alone. The pattern is shared but the work is distinct.
Snapshot copy in someli-mono-repo / someli-project Never edit. Re-generate from canonical if the snapshot is needed.
Two diverged Polotno editor folders Fix the affected fork; port to the other only with intent.