[FEATURE] consider using caret ranges instead of pinned exact versions for runtime dependencies

You pin almost all of runtime dependencies to exact versions. As of 2.40.1:

"dependencies": {
  "@inquirer/select": "1.3.3",
  "@nestjs/axios": "4.0.1",
  "@nestjs/common": "11.1.28",
  "@nestjs/core": "11.1.28",
  "@nuxtjs/opencollective": "0.3.2",
  "axios": "^1.18.1",
  "chalk": "4.1.2",
  "commander": "8.3.0",
  "compare-versions": "6.1.1",
  "concurrently": "^10.0.3",
  "console.table": "0.10.0",
  "fs-extra": "11.4.0",
  "glob": "13.0.6",
  "proxy-agent": "8.0.2",
  "reflect-metadata": "0.2.2",
  "rxjs": "7.8.2",
  "tslib": "2.8.1"
}

Only  axios and  concurrently  use ranges. Everything else is exact.

Consider using carets e.g.  "chalk": "^4.1.2" ,  "@nestjs/common": "^11.1.28".

We install your cli as dev dependency (we are not using it via npx). Why this is problematic (i bet not just for us).

• Duplicated packages / bloated installs. This probably does not need explanation, but in short this is especially painful for  @nestjs/*  and  rxjs  in projects that already use NestJS on a slightly different patch.
• Patch-level security fixes are blocked. If a CVE is published for a pinned transitive dependency, consumers cannot resolve it via  npm audit fix, overrides aside — they have to wait for a new release of this package. Every patch bump of an upstream dep requires a release here.
• Peer/version conflicts in monorepos and strict package managers
• Noisy dependency/SBOM reports. Under DORA (Digital Operational Resilience Act) we have to inventory and risk-assess our whole dependency tree — build-time included, since CI is part of the supply chain. Exact pins mean duplicate, outdated entries in our SBOM that we can't dedupe or patch ourselves, and each one becomes a manual finding to justify or waive. Being a  devDependency  doesn't exempt it from that process.

Thanks for considering it!

Finde das Paketmanifest und überprüfe seine Laufzeitabhängigkeitseinträge anhand des angeforderten Caret-Bereichsansatzes. Notiere dabei alle Abhängigkeiten, die weiterhin gepinnt bleiben sollten. Kläre die Bereichsrichtlinie mit den Maintainer:innen, aktualisiere das Manifest und führe die vorhandenen Installations- und Testprüfungen des Projekts aus, um zu verifizieren, dass die CLI weiterhin funktioniert.