`gts init` adds incorrect TypeScript version in pkg.devDependencies

[Yehyoung Kang]

When I run npm init-y followed by npx gts init in an empty directory, package.json contains the following:

{
  "devDependencies": {
    "gts": "^3.0.3",
    "typescript": "^4.0.3",
    "@types/node": "^14.11.2"
  }
}

However, the actual version installed is TypeScript 4.1.3, not 4.0.3:

$ npx tsc --version
Version 4.1.3
$ ./node_modules/.bin/tsc --version
Version 4.1.3

Since the actually installed version in node_modules/typescript/ is newer than the specified version, npm outdated does not report the discrepancy, and npm install does not fix it.

Due to how semver works, running npm ci will still install TypeScript 4.1.3. I therefore assume it won't cause any issues in CI. However, it could still cause developer confusion.

---

I reproduced this in two setups:

1. Windows 10 version 2004, Node.js v12.20.0, NPM 6.14.10
2. Windows 10 version 2004, WSL 2 (Ubuntu 20.04.1 LTS), Node.js 14.15.3, NPM 6.14.10

[Justin Beckwith]

Greetings! This is working as intended. When you add ^4.0.3 to your package.json, the ^ is super important. That tells npm "Install any version of TypeScript that's greater than 4.0.3, up to but not including 5.x". When you run npm install the first time, it's going to identify the latest version of TypeScript that matches the given range, which in this case would be 4.1.3. It is also likely going to pin to that version in your package-lock.json, until the next time you try to bump versions. All of this is just npm doing npm things, and completely separate from gts.

Chances are - this behavior is what you really want. I'm not sure if npm outdated takes package-lock.json into account or not, or if you're checking your lock files into source control. What we frequently do is use automation to do "lock file maintenance", where the lock file is regenerated weekly to keep everything up to date.

Hope this helps!