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

Tìm manifest của package và xem xét các mục dependency runtime của nó theo cách tiếp cận khoảng phiên bản caret được yêu cầu, đồng thời ghi lại mọi dependency cần tiếp tục được ghim phiên bản. Xác nhận chính sách khoảng phiên bản với các maintainer, cập nhật manifest và chạy các bước kiểm tra cài đặt và kiểm thử hiện có của dự án để xác minh CLI vẫn hoạt động.

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!