feat: shared logger library

[dnechay]

Issue tracking

Closes #3387

Context behind the change

Created a custom logger package that we can install using yarn workspaces and use across all apps. Also it can be used in any other HUMAN Protocol service after we publish it to npm.

How has this been tested?

• install logger in RepO and run yarn start locally to verify log messages
• run RepO in docker, check logs from docker container
• yarn pack to make sure all necessary files included into distro

Release plan

1. Merge
2. Publish to npm later
3. Use anywhere (aka migrate other apps to it)

Potential risks; What to monitor; Rollback plan

Should be none

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
human-app	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 8, 2025 10:58am
human-dashboard-frontend	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 8, 2025 10:58am
staking-dashboard	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jul 8, 2025 10:58am

2 Skipped Deployments

Name	Status	Preview	Comments	Updated (UTC)
faucet-frontend	⬜️ Ignored (Inspect)	Visit Preview		Jul 8, 2025 10:58am
faucet-server	⬜️ Ignored (Inspect)	Visit Preview		Jul 8, 2025 10:58am

[portuu3]

@dnechay What do you think about moving logger folder from rep oracle into common?

[Dzeranov]

@portuu3 @dnechay
What do you think about moving this logger package into a different repo?
I mean, we have plans to publish this package and use it across the monorepo from npm. Might be worth discussing.

[dnechay]

@portuu3

What do you think about moving logger folder from rep oracle into common?

I wouldn't, because IMU logger belongs to some sort of infrastructure level, where we might have database, cache, queue and other similar things. Right now we have only database and logger, so it's fine to keep them directly in src, but we can have src/infrastructure for that

@Dzeranov

What do you think about moving this logger package into a different repo?

TBH, I don't fully understand the purpose and boundaries of this monorepo (what is the initial idea to have it) and perceive it like "catch-all HUMAN Protocol". We have sdk package here, which is also published to npm and can be used elsewhere, so I don't see benefits of moving the logger out of here.

At the same time, we can discuss the boundaries and purpose of monorepo, so after that it becomes clear where to place things. My vision is next:

• we have humanprotocol org
• we have one monorepo to work with contracts and blockchain stuff, which includes:
  • current core workspace
  • all the sdk stuff for any language
  • subgraph staff
  • these should be published to npm, respect semver contracts and be used only as package installation
• we have one monorepo with oracles and other necessary apps that protocol runs itself

The latter will definitely need some packages/shared or packages/libs that will hold some shared code and we won't even need to publish it to npm, because only our oracles will use that. If we think that something might be useful outside of this repo (e.g. logger), then I would have one repo per thing (or we can have some humanprotocol/misc monorepo with all things like this, but it's overhead IMO)

[Dzeranov]

Lets merge it for now, we might want to revisit in case we change monorepo setup.