@mikro-orm/cli always installs latest version of @mikro-orm/core, not its equivalent version

[rcfox]

Describe the bug
While I'm waiting for the fix for #3442 to be released, I thought I would try an older version (5.2). However, the cli package always installs the latest version, which it then complains about being incompatible. I think this might be due to the ^ in front of the dependency version in the package.json.

Stack trace

(node:40807) UnhandledPromiseRejectionWarning: Error: Bad @mikro-orm/cli version 5.2.4.
All official @mikro-orm/* packages need to have the exact same version as @mikro-orm/core (5.4.0).
Only exceptions are packages that don't live in the 'mikro-orm' repository: nestjs, sql-highlighter, mongo-highlighter.
Maybe you want to check, or regenerate your yarn.lock or package-lock.json file?
    at Function.checkPackageVersion (/home/rcfox/test/node_modules/@mikro-orm/cli/node_modules/@mikro-orm/core/utils/ConfigurationLoader.js:222:23)
    at async Function.configure (/home/rcfox/test/node_modules/@mikro-orm/cli/CLIConfigurator.js:25:9)
    at async /home/rcfox/test/node_modules/@mikro-orm/cli/cli.js:13:19
(Use `node --trace-warnings ...` to show where the warning was created)
(node:40807) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 1)
(node:40807) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

To Reproduce
Steps to reproduce the behavior:

1. mkdir test && cd test
2. yarn add @mikro-orm/core@~5.2
3. yarn add @mikro-orm/cli@~5.2
4. yarn mikro-orm debug

Expected behavior
@mikro-orm/core version should match @mikro-orm/cli version.

Additional context
Here's what I see in my yarn.lock:

"@mikro-orm/cli@~5.2":
  version "5.2.4"
  resolved "https://registry.yarnpkg.com/@mikro-orm/cli/-/cli-5.2.4.tgz#9b4bd5212985ed080d21356c639be96f0ea92536"
  integrity sha512-eS+MsBWv/a3dxJSGym0XWWxGL4Ll77PQAZUPHRYNLS1h2u/hLC8TzxKDxK+wCBBklRvmgD/YvPs8V73x243u6w==
  dependencies:
    "@mikro-orm/core" "^5.2.4"
    "@mikro-orm/knex" "^5.2.4"
    fs-extra "10.1.0"
    tsconfig-paths "4.0.0"
    yargonaut "1.1.4"
    yargs "15.4.1"

"@mikro-orm/core@^5.2.4":
  version "5.4.0"
  resolved "https://registry.yarnpkg.com/@mikro-orm/core/-/core-5.4.0.tgz#29432927e6b8462a5ed00e638e523e5c6dd9e895"
  integrity sha512-x7H7X3EOxyiEuW0kqujTDTGPQsF0iUNHKMh7xxEhzj+4BlYebiAsmTtekoFJ500kcXqt7ICbcOu3RmfLcUSC4w==
  dependencies:
    acorn-loose "8.3.0"
    acorn-walk "8.2.0"
    dotenv "16.0.2"
    fs-extra "10.1.0"
    globby "11.0.4"
    mikro-orm "^5.3.1"
    reflect-metadata "0.1.13"

"@mikro-orm/core@~5.2":
  version "5.2.4"
  resolved "https://registry.yarnpkg.com/@mikro-orm/core/-/core-5.2.4.tgz#2e8b1a2d9f6b20239a71a81e65bba6265df2e144"
  integrity sha512-oT8vxF4/AlsfkbS5FFVPa3eotrfOwIursJS+LYAnNz9b6V/1K+DboMkhQqYeUq0yQx+8RRxd3hbGiX235wXuJw==
  dependencies:
    dotenv "16.0.1"
    escaya "0.0.61"
    fs-extra "10.1.0"
    globby "11.0.4"
    mikro-orm "^5.2.4"
    reflect-metadata "0.1.13"

Versions

Dependency	Version
node	14.17.6 / 18.8.0
typescript	?
mikro-orm	5.2, 5.0

[B4nan]

Interesting, apparently instaling the orm/knex package explicitly helps:

https://stackblitz.com/edit/mikro-orm-repro-alhc8a?file=package.json

edit: I dont see anything wrong with how the deps are structured, but if anyone knows how to get around this, I am all ears. I dont think we should pin the ORM package deps (that would obviously fix it).

[B4nan]

Right, that sounds like a good idea

[B4nan]

Lets see how it works when we reach v5.5, we cant do anything about past versions I guess. Maybe backport and ship new patches for them, but it seems like unnecessary work, with 5.4.1 stable things should be alright again.

fdbf67c

[SpencerKaiser]

Yea I really don't think this is a huge issue in the first place, but I think that will certainly help!

The only reason I stumbled upon this in the first place was because I just nuked my yarn.lock and noticed some issues due to breaking changes on the minor release. I'm wasn't surprised by the breaking change, but I was surprised when the breaking change was in a dependency of my dependency.

TL;DR - I don't think this will be a common issue but I think your patch helps 😄

[B4nan]

Hmm apparenlty lerna version changes it back to ^ and its impossible to control this. Changed it manually for now, but this will be quite error prone...

[SpencerKaiser]

If that's the case, I'd say the original setup was was probably preferable... worst case scenario, someone can add a dependency resolution (if they're using yarn... otherwise I'm sure there's something similar for npm). I think you're right that it'll be quite error prone and it's gonna make your personal developer experience a lot worse because you'll have to keep them all in sync all the time (unless you script that out into an Action, which also sounds like a lot of work 😅)

I can only think of two scenarios for when this would be problematic:

• People duplicating old projects and cleaning up their dependencies (old code + new version which might cause trouble if there are breaking changes to the minor version of a dependency).
  • This was my use case and I wouldn't put the responsibility on you to fix this... The only other
• People nuking their package.lock file and reinstalling dependencies (they're gonna have a ton of problems anyways because ALL of their dependencies are gonna update...)

Can you think of any other potential scenarios where this will be an issue?