[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!

Locate the package manifest and review its runtime dependency entries against the requested caret-range approach, noting any dependencies that should remain pinned. Confirm the range policy with maintainers, update the manifest, and run the project's existing install and test checks to verify the CLI still works.