Stop using yarn.lock and pin the exact versions of dependencies in the package.json files

[thomvaill]

Following the incident caused by a breaking change released in a dependency which does not follow semver: #74
And because of these reasons: https://gajus.medium.com/stop-using-package-lock-json-or-yarn-lock-909035e94328
I think we should not use yarn.lock anymore, and pin the versions of the project dependencies more strictly, and maybe use a tool like Renovate to assist us with their upgrades.

[mervyn-mccreight]

Not sure whether it's a good idea to not put the yarn.lock into version control regardless, since this is not a library but rather an application (or is my impression on what log4brains is wrong?) and it helps with reproducibility. Even if you define your dependencies in a strict way, the transitive dependencies most likely are not defined like this and could possibly change without a yarn.lock making the build non-reproducible, or am I wrong about this?

Regardless of that, using strict dependency version notation in the package.json is a very good practice IMO.

[thomvaill]

Yes it is an app but since it's installed with npm install -g log4brains the yarn.lock file is not taken into account by users (or maybe I'm wrong?)
Of my understanding, the yarn.lock file is only taken into account when we develop on the log4brains project, which give a false sense of reproducibility since this is not the case of our users.
Whereas pinning exact versions in package.json will ensure both of users and developers use the same versions